RE: SGML, DTDs, EDDs, and FOSIs

[larry.kollar@xxxxxxxxxx]

Eric Dunn wrote:

> Seems to me the most ridiculous thing about SGML/XML/**ML is that they 
are all
> sold as easy ways to exchange information. However, the entire structure
> including the language of the specifications, the proprietary 
implementations,
> information hoarding by consultants, and the high priesthood/secret 
society
> behaviour of those in the know, all prevents the easy interchange of
> information.

I have to take issue with that statement, at least as it applies
(or not) to XML. If you had limited the charges to SGML, I would
have said "AOL" and moved on. :-)

XML specifications are available at www.w3c.org and are fairly
readable. The XSLT spec came to <50 printed pages and was easy
to understand (at least for me). There's a lot of alphabet soup
floating around XML right now -- Xpath? Xlink? Xpointer? -- but
the useful stuff will stick around & the rest will fade away.

A quick look at the open source world will yield scads of XML
software, from non-validating parsers like Expat to XSLT processors
like Sablotron or Xalan, libraries like xmllib2 for Xpath, and so
on. The Java world has really come through, producing all sorts of
processors and at least two free XML databases that I know of.
There's a free Java-based XML editor called XMLmind that does a
decent job of authoring small documents, and others (Morpion
comes to mind) are fairly low cost and provide more functionality.

Finally, it's quite easy to bypass the priesthood (such as it is
with XML, they tend to be more evangelical than qabalistic) and
hoarders, and find info on mailing lists, newsgroups, and websites.
O'Reilly's xml.com is a good place for tutorial articles and the
like. In contrast, SGML got under way in 1980 -- when there was no
Internet to speak of, and sharing code and specs was difficult
even for those who wanted to (you could ship magnetic tape reels,
assuming both ends had compatible tape drives).


> Even more infuriating (to me at least) is that so many of the
> principles and techniques are so blazingly simple yet presented in such
> arcane/black magic manner. Take FM SGML applications for example. 
Consultants
> throw around "application" as if it's some giant development project. 
Cripes, it
> only means you have a template, EDD, DTD, and read/write rules.

No argument there -- it took me nearly a week to get it through
my head that an "application" didn't mean "binary executable" in
FM+SGML context. But having written an EDD, I can safely say that's
no picnic (especially if you learn it on the fly like I did).
Let's hope that FM7 will demystify some of that.


> Perhaps, if Adobe is serious about pushing FMs structural documentation
> capabilities they could produce a truly standards compliant SGML/XML
> implementation. Certainly if Adobe would develop some solid transform 
tools to
> import/export other formatting standards they could gain a lot of the 
market
> share currently held by Adept.

If FM7 does a good job of importing & exporting XML, then external
tools can do the rest -- and that's good, it means you can tailor
the environment. The hard part, IMO, is still working with EDDs &
I don't expect that to change. Part of the problem there is that
you define structure from the top down but formatting from the
bottom up. If you're like me, and don't know what you're doing at
first, the thing can get out of hand in a hurry & you'll end up
rewriting it just to make it maintainable.

--
Larry Kollar, Senior Technical Writer, ARRIS
"Content creators are the engine that drives
value in the information life cycle."
    -- Barry Schaeffer, on XML-Doc


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