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

Subject: Re: Interesting XML discussion from TechWr-L [long]
From: Dan Emory <danemory -at- primenet -dot- com>
To: Chris Despopoulos <cud -at- arrakis -dot- es>
Date: Tue, 30 May 2000 04:48:09 -0700

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 -at- primenet -dot- com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo -at- omsys -dot- com with "subscribe framers" (no quotes) in the body.






Follow-Ups:

Previous by Author: Re: Samples of Software/functional specification docs
Next by Author: Re: Interesting XML discussion from TechWr-L [long]
Previous by Thread: RE: I have found the Holy Grail of technical writing!
Next by Thread: Re: Interesting XML discussion from TechWr-L [long]


What this post helpful? Share it with friends and colleagues:


Sponsored Ads