Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Proposal Announcement - XML DTDs to XML docs
 It's good to get feedback. Paul Prescod stated: >Another problem is "specification encapsulation." XML 1.0 is specifically >designed NOT to depend on XLink or XPointer. Your proposal depends on >them. It seems to me that there is some sort of circularity problem there. I think this circularity problem is not too difficult to cope with in practice. It could be reduced, if not disposed of, by decomposing XML 1.0 into three different specs: 1) A document syntax specification (a simplified version of well-formed documents) 2) A syntax for linking to DTDs (and perhaps schemas) internal or external (which would depend on XLink) 3) A syntax for DTDs providing rules for validation. (Schema definitions could rest on top of #3 or beside it.) Even if these seems inadequate, I think it would be useful to reduce the number of ways users and developers reference external resources from XLinks, general entities, parameter entities, notations, and assorted other goodies to a single URI-based spec with consistent notation, preferably XLink. >Nobody has ever done the work to flesh it out to the point where an >XML-document notation is as expressive as the current DTD notation. I >believe that people who have not been using the DTD notation for a long >time underestimate the extent to which common use depends on weird stuff >like parameter entities specifying partial content models, element types >in element type declarations and so forth. I realize that these are significant challenges, and that conversion to an XML document format for DTDs doesn't whisk them away. What I'd like to see is a determined effort to map the 'weird stuff' to XML DTDs. Note, for instance, that I kept the SGML-like content model in my examples. It's sort of a half-way step, leaving in some of the old that the new may prosper. As for parameter entities, I think they can be expressed as easily through the model I presented. Fleshing this out is admittedly a large task that I don't think I can manage alone. >A user interface >(markup languages *are* user interfaces) can be too consistent, if it >obscures the differences between things. In the case of documents and >DTDs, I expect many users would get confused about the distinction between >documents and DTDs if DTDs *were* documents. This is a significant consideration I hadn't noticed, and I'll address it more directly in the next revision. I don't think it's insuperable. >There is also the issue of compatibility. If the DTD for DTDs is >extensible and open, as most proponents argue it should be, then >Microsoft, Netscape and Sun can all take shots at "extending" it in the >way that they "extended" HTML. If the DTD DTD was specifically designed to >be extensible, then we could not complain about that. Depending on the >level of extensibility, XML documents could actually parse differently >depending on which browser you were using. If it was designed NOT to be >extensible, then we have to cross one of the benefits of this alternate >notation off of the list. I would certainly want this to be extensible; parsers that didn't understand an extended portion of this DTD could simply ignore that portion, provided the document met the basic rules. I don't see this as a significant problem, especially after looking at several of the schemas other people are proposing for XML documents. XML is going to fragment to a certain extent; I'd like to see the core made more extensible to provide an orderly framework for such extensions rather than letting them run off on their own. >Several of my complaints about your proposal stem from the fact that DTDs >both change the parse and validate the document. In other words, they are >both schemata and "parse information providers". If your XML-instance DTDs >only validated, then many of the complaints would go away. But if they >only validated, I don't think it would be accurate to call them DTDs >anymore. Then they would be just "schemas" since they would accomplish >only one of the DTD's two functions. I think you miss part of the point - that this is a representation intended to completely represent the same data that is provided currently by XML DTDs. You seem to assume that there will be data lost in the transition, without pointing out where it would be lost. I think you could build the same schemas and parse information with this system as you could with the current XML DTD structure, while providing the extensibility that several other proposals seem to need. I would rather _not_ provide full schema information in this proposal - moving XML DTDs to a new format seems like enough of a task to start with. In the long run, of course, DTD would be an inadequate term to describe these. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
