xml-dev - RE: Parents and children (was RFD: comp.text.xml)

["W. Eliot Kimber" <eliot@isogen.com>]

At 01:30 PM 5/6/98 UT, Simon St.Laurent wrote:
>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:

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

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:

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

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>
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)