Re: Interesting XML discussion from TechWr-L [long]

[Chris Despopoulos <cud -at- arrakis -dot- es>]

Let the comments' comments commence...

Dan Emory wrote:

> Your approach doesn't match up well with Adobe's way
> of doing business. The meager improvements in V6.0
> shows what happens when there is no organized and
> coherent demand for real improvements. V6.0, after
> all, was the first new major release in more than 4
> years.

>
> In the past, Adobe has only listened to what
> the major license holders have demanded. And I
> do mean demanded. About 10 of the biggest
> license holders ganged up on Adobe to press for what they
> wanted in V5.5. They threatened to abandon
> FrameMaker unless they got what they wanted.

What were the improvements they demanded?  That Adobe enter into the
Asian market?  As far as I know, that was the biggest and most
fundamental change in Maker for that release.  As far as I can tell, it's
exactly the kind of change I'm talking about...  A deep change of
architecture that opens the product up to a wider, growing market.  Note,
the number was 5.5...  Indicating it was a half-release, if you ask me.

>
>
> Immediately after the original V5.5 was released,
> there was an attempt by a group of 40 or 50 framers
> list participants to formulate a list of features needed
> in the next major release. When V5.5.6 came out
> none of the suggested improvements were included,
> and certainly none are in the new V6.0.

5.5.6 was primarily a fix to issues that cropped up as a result of
including double-byte characters in the product.  Expecting a list of
features to show up in a patch is ambitious.   But notice that the SGML
API did get improved entity support in the deal...  Very important for
the market we're talking about.

>
>
> I thoroughly disagree with your suggestions that
> some of the fundamental features needed in FM+SGML to
> fully implement XML could be done through
> API's development. If FM+SGML is
> going to be a player in the XML arena, it's development is going
> to be an evolutiionary process that will probably extend across
> several releases timed (hopefully) to coincide
> with the firming up portions of the XML standard that
> are still in a state of flux. Such a phased approach is
> absolutely incompatible with outside API development
> to provide key functions within the XML part of the
> product.

If it's going to be a player, it's going to need a parser and Unicode.
Just how easy do you think it is to get that into the product?  And how
cheap (er, expensive)?  If I have any point at all to make here, it's
that we need this fundamental (and expensive) change in the product
before *anything* else.  By comparison, everything else is fluff, and
will prove meaningless as customers who need XML support migrate to other
products.

Phased approach to improved XML support?  Of course.  That's how software
is developed.  It is *not* absolutely incompatible with API development.
Would you suggest Adobe never add features to Maker via the API?  What
about filters, table sort, HTML export, XML export...  The fact is, API
development is already a part of Maker evolution.  Another fact...  The
vast majority of real-world SGML applications of Maker+SGML also use API
development.  You may not use the API - I would then call you the
exception that proves the rule (whatever that means, but my parents said
it all the time).  But ask around and you'll find that API development is
a part of the industrial installations.  And as far as I know, Arbor Text
demands heavy development for real-world installations, too.

>
>
> The fact is that the vast majority of FM+SGML
> license holders are unwilling to undertake the kinds
> of API development tasks you're describing below, for
> the most fundamental of reasons: Each time
> Adobe issues a new release of FM+SGML, it
> may punch a hole in those APIs. That was the
> dilemma faced by Boeing and many other companies
> who were using Interleaf. They had so much
> custom stuff festooned onto the current release that
> they were frozen in place, unable to upgrade to any newer
> Interleaf releases.

This is untrue.  Typically, if your API code doesn't call on the new
stuff, a new rev has no effect on your plugins.  But let's take something
that changed fundamentally, like page numbering in 6.0.  If your FDK code
hit page numbering, you can still use it unchanged, except that you need
to add a preprocessor call to use behavior of the earlier version of the
product.  This is a fundamental part of revisions to the Maker API...
Backward compatibility.

I can't say whether InterLeaf offered that, or what else the problems
were with it.  I do know that they marketed their own developers because
developing in InterLeaf was hard...  LISP based, I believe.

And I hold to my assertion that the vast majority of real-world
installations use API code.  I suspect on this one we will enter into a
"Did too!" - "Did not" - "Did too!" - "Did not" - "Did too!" - "Did not"
- "Did too!" - "Did not" - "Did too!" - "Did not" - "Did too!" - "Did
not" - "Did too!" - "Did not" type of argument.  Hmmm...  It would be
nice to see some numbers on this.  Maybe you're saying the type of API
development I'm suggesting is too big?

What I'm suggesting is this:

If Adobe gives me nothing more than Unicode and XML parsing within a
year, I can make do until the next release.  That's all I'm saying.

>
>
> That's the dirty little secret about custom APIs
> that never gets mentioned by those who glibly
> suggest an API solution for almost anything the
> product can't do out of the box.
>
> What Adobe must do if FM+SGML
> is going to become a fully functional XML tool is to
> publicly commit to that goal, and the concomitant
> long-term development process whose
> stated objective is to assure that the product
> remains on the cutting edge as the XML standard
> evolves and firms up.

Absolutely.  And the first sign of commitment?  Parser and Unicode.
Believe me, if you want to see it within a year, don't ask for too much!
There's so much to Q/A in just those two things, they may have already
(yet again?) fallen off the list!

That's one problem with the commercial process here.  5.5 is a perfect
example.  Adding double-byte characters was a huge effort, and a
tremendously valuable change to the product.  But us proles didn't get
too much value from that.  On the other hand, the effort made it
necessary for other "favorite" enhancements to fall off the list - not
enough dev and Q/A resources.  So Adobe couldn't call it a full version
upgrade, in spite of the time it took to accomplish.  And so it was
difficult to sell the upgrades and get the needed revenue.  Then the bean
counters had ammunition to pull resources out of Maker development.
Which brings us to 6.0, and you're already complaining that the
enhancements are lame!

Ok, so the above is speculation.  But I suspect some of it will ring
true.

>
>
> That kind of explicit public commitment is what is needed
> now to gain the confidence of companies and individuals who are
> already beginning to decide which tools they will use
> when XML starts to become dominant.

It was needed yesterday, if you ask me.  Look, all I'm asking for here is
the start.  There's plenty we could ask Adobe to do with Maker.  But I'm
talking about merely staying in the game.  If Maker can stay in the XML
game, then people can use it instead of turning to Arbor Text.  As they
use it, they will begin to spell out to Adobe exactly which features are
necessary and/or will save them yet more time and money.  Dan, I'm sure
you have plenty of experience with the tool that leads you to obvious
improvements.  I'm just saying, stick to the fundamentals for now, and
trust that the improvements that are possible will come...  Assuming they
can generate revenue.

cud