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

[Dan Emory <danemory@xxxxxxxxxxxx>]

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.

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.

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.

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.

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.

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.
==========================================
At 10:25 AM 5/30/00 +0200, Chris Despopoulos wrote:
>I tend to be conservative in my requests, and I try to ask
>for fundamentals rather than asking for everything.  If the
>fundamentals are there, and they include hooks to add in the
>fancier stuff later, that's good enough for me.

---------------------------------Snip-----------------------
>MUST HAVE:
>A true XML parser in Maker+SGML.  I suppose it should be
>event based since the SGML API is event based.  Also, I
>suspect that's better because many of the Maker customers
>are dealing with HUGE documents, and loading a full tree in
>memory may not be a good idea.  If I had leave to dream, I
>would ask for modular incorporation of the parser, with
>hooks for me to change parsers via the API.  Certainly, it
>should be made easy for Adobe to change parsers!
>
>Unicode.  Maker already supports double-byte characters.
>Let's fully support Unicode.
>
>VERY NICE TO HAVE:
>A sample API client that is a net client.  XML includes URL
>links to DTD's, entities, etc.  Just show me how to include
>that in my Maker environment.

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

>XSL support.  Either that, or a sample API client that is a
>subset implementation there of.  In fact, whatever XSL
>support you provide, do it via the API, and give me the
>source.  If it isn't ready for prime time, call it an API
>sample, and give it minimal Q/A.  If it is ready for prime
>time, call it a feature.  But give me *something* here.
>
>NICE TO HAVE:
>Full link support.  But I can always translate Maker xrefs
>into whatever type of link I need via the SGML API.  So I
>would not sweat it if that wasn't there in 7.0
>
>XSL/CSS translation to and from EDD formatting...  This is
>Dan's request, and it would be nice.  But I believe that is
>something a third party could develop via the SGML API.  It
>would be nice for Adobe to do it, but there may not be the
>business case for it.
>
>Pretty modest, eh?
=============================
Far too modest, I fear.




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