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

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 06:50 PM 5/30/00 +0200, Chris Despopoulos wrote:
>Let the comments' comments commence...
> > 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.
>==================================================

I didn't say they got everything they wanted, but it took coercion
to force Adobe to give them anything at all.

> >
> >
> > 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.
>================================================

All I was pointing out that even 40 or 50 people from the US
and Europe, most of them long-time Frame users who could
qualify as experts, who arrived (more or less) at a consensus
on what was needed got nothing from Adobe.
========================================

>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.

We need to get real about what Adobe is doing with FrameMaker.
They' (I mean Warnock, Mark Hilton, et al) are not willing to publicly
commit to a long-term, phased development project which will
result in giving users what they need in order to continue using
the product. They won't even publicly commit to fixing nasty
bugs in the next release. Most of us know nothing about what
features the next release will have until it hits the street. Notice
that, for V6.0, there were hardly any leaks that got out even
during Beta testing. And we certainly have nothing but educated
guesses about any Adobe strategy extending beyond the next
release.

You, Chris, are saying you somehow know that Adobe has
a multi-release development strategy for developing the XML
capability, thus you whittle down your wish list and say
"Just give me this much in the next release and I'll be happy,
even though it's not enough."

I say that until Adobe publicly commits to a multi-release
development strategy for FM+SGML we must demand all
the functionality that is required to make FM+SGML a
viable XML tool worthy of serious consideration.

Acceptable responses from Adobe to such demands might be:

1. No way Jose. (that at least tells us to look elsewhere)

2. We'll commit to a long-term development strategy
that will lead to all the functionality you're asking for.

Unacceptable responses from Adobe would include:

1. We cannot commit to giving you anything, but
maybe we'll try to give you some of it. But you
won't know what, if anything, we're going to do
until the next release hits the street, and we're not
about to tell you when that will be.

2. The kind of Adobe marketing crap regarding FrameMaker
that is the only thing we've heard ever since they took the
product over.

> > 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.

Apparently you're not a believer in Murphy's Law. I am.
LISP, WISP, whatever. It wasn't the language problem that got
Boeing in trouble, it was fixing product deficiencies with their
own custom code. This custom stuff was integral to their
work flows, and the mere thought that something bad might
happen if they upgraded to the next release was enough
to freeze them.

>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.

Oh boy if you start from that position with Adobe, you're almost certain
to get less than that, and no commitment to provide anything more
in future releases (they won't even say there will be any future releases).

>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.

-------------------Snip-----------------

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

Well, I know a little about what went on in Adobe at that time.
The original V5.5 was an attempt to capture the Japanese market,
and nothing more. That priority took precedence over fixing bugs
and inadequate "features" that had been pending for years.

And now we have V6.0--the first major new release in over 4 years.
What do we get? Book-wide commands, that's what, even though
there are APIs and framescripts already available that will do most
of them. What else? Why WWP lite, of course. Adobe did the same
thing in the initial V5.0 release, and it was a total fiasco.

====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo@omsys.com with "subscribe framers" (no quotes) in the body.



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **