>During the excitement this weekend over these issues, I wrote an essay
that
>more completely describes my take on these issues. I'm still tinkering,
but
>the basic framework is there. You can check it out, if you like, at:
>
>http://members.aol.com/simonstl/xml/lettinggo.htm
>
>Comments and suggestions are welcome, though this list may not be the
right
>place for that. The document has already been strengthened by a number
of
>assaults; just try to keep them friendly.
I took a quick look at the paper and I think I generally agree with
it--the approach Simon outlines is completely consistent with the
marketing objectives that drove XML from the beginning. He also makes a
clear distinction between use domains that require full strength SGML
(and can therefore afford to implement its use) and use domains that do
not. This is a key message:
XML->full SGML represents a continuum of cost/value that you can choose
any point along. XML clearly defines one end, the other end is, to some
degree, undefinable but could be defined as the union of all SGML
facilities. Most workaday production applications need something just to
the right of XML.
The only quibble I have is with this statement:
>>>>
<excerpt>The divergence of the supporting XML standards (XML-Linking,
XPointers, XSL) from their SGML equivalents (HyTime, TEI, DSSSL) suggests
that XML is in fact developing separate practices and a separate set of
application tools.
</excerpt><<<<<<<<
Because of the highly general nature of the HyTime and DSSSL standards,
it is difficult or impossible to diverge from them in any irreprable way.
This is because the semantics they embody are more or less universal (or
at least well established). Because these standards are semantic
standards first and syntax standards second, changes in syntax are
largely irrelevant. Case in point: XLink. This means that the tools that
support these general standards generally should always be able to
support corresponding XML-specific applications with a minimum of extra
effort (ideally none).
The XLink architecture can be easily defined as an application of the
HyTime architecture for those parts that have an analog in HyTime (HyTime
doesn't have an opinion on behavior or presentation, so the show and
embed attributes are unique to XLink). As long as you're using SGML or
XML syntax, the details of the representation in a given document are
irrelevant because you can always use HyTime's declaration mechanisms to
map whatever you're doing (or what someone else did) to the corresponding
HyTime facility. [I will soon release a freeware HyTime engine that
demonstrates this by treating XLink as an architecture derived from the
HyTime architecture, through which the general HyTime linking support
will be applicable to any XLink document, SGML or XML.]
DSSSL is the same way: the set of primitive semantics needed for
formatting are pretty well established. The only questions are details of
syntax and processing model. But because DSSSL is already established
and implemented, it will be easy to apply those semantics to new syntaxes
(e.g., XSL) unilaterally, thus leveraging the existing base of software
and knowledge about DSSSL at minimal incremental cost.
But...the average XML user doesn't need to know this. These Borg-like
assimilations can be done unilaterally without disturbing the
XML-specific standards (except possibly to suggest, during their
development, that if they did X or Y small thing, it would make future
assimilation easier).
I do agree generally with the second half of the statement:
>>>>
<excerpt>The need to broaden the audience of XML beyond the current SGML
community (if XML is to attain ubiquity) suggests a need for texts,
forums, and tools which are aimed at XML-only development, and aren't
simply renamed SGML texts, forums, and tools.
</excerpt><<<<<<<<
As long as there is always somewhere a clear discussion of the history of
XML and its relationship to its progenitors and relatives--in the same
way that every HTML book mentions HTML as being an application of SGML.
At the same time, it is encumbent on the developers of ISO standards to
present their standards in a way that will make them more accessible to
the XML community so that when they want to move up to more facilities,
the incremental cost is consistent with the increase in value. This is a
tall order for SGML in particular because it represents a singularly
non-trivial technical writing task, but it's one that I think we (the
SGML committee) have agreed is necessary. How we will achieve it or
when, I don't know....
Cheers,
E.
--<<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202. 214.953.0004
www.isogen.com
<</Address>