- From: James David Mason <masonjd@ornl.gov>
- Date: Mon, 30 Sep 1996 13:49:24 -0500
- To: Rick Jelliffe <ricko@allette.com.au>
- Cc: "Charles F. Goldfarb" <Charles@sgmlsource.com>, w3c-sgml-wg@w3.org
At 01:54 AM 10/1/96 +1000, Rick Jelliffe wrote: >Is this really more what XML should be about: a markup language for >presenting documents in the form required by the application? (Which >would correspond to the normalised form of an SGML document when parsed >against archetectural forms that model the XML application.) In other >words, a temporary/application/closed-system format rather than a >archiving/modelling/manipulation/open-system format like SGML. (no flames >about 'format' please) > > I've been staying quiet in this discussion group, but Rick's comment provides me the opportunity for saying something I've been thinking increasingly for about a week: Are we trying to do here the thing that ODA *should have been*? That is to say, is an XML document something that has structure, though perhaps not the kind of structure most of us have put in traditional SGML applications. There has been some discussion of deducing a DTD, using a tool like FRED, but is even that what we need? Charles and I wasted plenty of time dealing with ODA, and I'd hate to replicate that experience. But we did learn some things from it, like what led to architectural forms. It would be a great mistake if, while trying to simplify building applications on something that was related to SGML, we wound up getting so convoluted as ODA became (so convoluted it was unimplementable). However, their original idea was implicit logical structures, things that could be drived from tracing levels of nesting. I think that's what I'm hearing here. I'm one of the folks who believes in mandatory DTDs, but that's because most of the applications I deal with fall into what Rick calls a "archiving/modelling/manipulation/open-system format". Maybe there is a valid case for implicit structure in a "temporary/application/closed-system format". If we go that route, we really do need to keep things simple and avoid overspecifying. Jim Dr. James D. Mason (ISO/IEC JTC1/SC18/WG8 Convenor) Lockheed Martin Energy Systems Information Management Services SGML Systems Development 1060 Commerce Park, M.S. 6480 Oak Ridge, TN 37831-6480 U.S.A. Telephone: +1 423 574-6973 Facsimile: +1 423 574-0004 Network: masonjd@ornl.gov
Received on Monday, 30 September 1996 13:51:02 UTC