- From: Michael Sperberg-McQueen <U35395@UICVM.CC.UIC.EDU>
- Date: Thu, 12 Sep 96 14:37:00 CDT
- To: Martin Bryan <mtbryan@sgml.u-net.com>, W3C SGML Working Group <w3c-sgml-wg@w3.org>
On Thu, 12 Sep 1996 14:09:57 -0400 Martin Bryan said: [quoting myself]: >>More seriously, it's hard to imagine just how to tell existing SGML >>software how to emit a legal XML document using this mechanism, which >>means every time I touch my XML documents with an SGML tool, I am >>punished by being required to run a little cleanup filter. > >Such a filter is no worse than the one you would have to write to >remove the end-tags from XML-EMPTY elements before sending them to a >validating SGML tool! You can't win with either approach, ... Remember that empty XML elements have to be empty SGML elements, but they don't have to be *declared* empty. An XML document might go into an SGML tool with an Elephant's-Child DTD -- no end-tag removal filter needed. >>7 Cooked Bits. A variant of the Raw Bits (parse it and like it!) >>approach would be to provide a different syntax for the declarations, >>to make them really, really easy to parse. > >Bang goes any chance of being able to use SGML tools to generate XML! Actually, it's the hope of using SGML tools to work on and generate DTDs (or the XML equivalent) that motivates this possibility. Like several other people, I decided some time ago that the easiest way to get good tools for working with DTDs was to use my existing SGML tools. Since they, unfortunately, only worked on instances, not on DTDs, this involved turning DTDs into instances (of a DTD for DTDs). Result: I can now write DTD transformations using the same tools I use for transformations of SGML documents. (One style sheet, of course, reads the DTD pseudo-instance and emits a DTD in 8879 notation.) I was very proud of myself for this trick, which I thought was unique until I learned that Wayne Wohler had already done the same thing for the CApH (Conventions for the Application of HyTime) committee, that Omnimark (then Exoterica) did the same thing to make Omnimark into a DTD-processing tool, and one or two or three other people whose identities escape me at the moment had all already done the same thing. Moral: this is not at all an eccentric idea. Nor does it pose any difficulties at all for using SGML tools to emit XML instances, or vice versa. XML *instances* are SGML *instances* -- I don't think we want to guarantee as much for the prologs. At least not yet, not without a lot more serious discussion. It's also easily thinkable that XML processing tools could provide all the functionality that make Bob Streich want to keep marked sections. We might want to have marked sections in XML, I don't know. But we don't *have* to have them, just because they currently provide essential function. It's the function that's essential, not the construct of the marked section. If we can find another way of providing that essential function, we don't need the marked section. DTDs-as-instances would make it trivial to implement the kind of DTD normalizers that many people have implemented. In the current notation, they appear to be trivial to implement only if they don't have to work correctly on all DTDs. -C. M. Sperberg-McQueen
Received on Thursday, 12 September 1996 16:03:33 UTC