Re: Proposal Critique - XML DTDs to XML docs
>>Every attempt didn't quite do everything that everybody needed, and >>the harder people worked to make languages "extensible", the more complex >>(C++) or merely unpopular (Lisp) the language became. I think this is a good point and an excellent argument for Simon's proposal. This language will be a very useful tool for a subset of users who dont want the hassel of learning a DTD language. There are always going to be things that a DTD is necessary for, but that doesnt mean that this is the only tool one should use. On the other hand if a language tries to be something to every one it is in danger of becoming like a swiss army knife. It will perhaps do the job, but not as well as a specialized tool. Frank -----Original Message----- From: Paul Prescod <papresco@t...> To: Xml-Dev (E-mail) <xml-dev@i...> Date: Friday, May 22, 1998 2:46 PM Subject: Re: Proposal Critique - XML DTDs to XML docs >Simon St.Laurent wrote: >> >> >Is there any good reason that the ability to change the parse tree should >> >be conflated with the responsibility for verifying schema-compliance as >> >they are in DTDs. Is there any good reason to perpetuate this conflation >> >in your proposed replacement for DTDs? >> >> I'd like to see a structure that's: >> a) easily interpreted, edited, and stored, without the need for multiple >> toolsets >> b) capable of containing a complete set of information about a document, >> including structure and data > >The word "structure" is too vague for me to be able to argue for or >against. Are you talking about a single *language* (or specification) that >incorporates > > a) instance syntax > b) textual replacement > c) external text embedding > d) extensible validation > >XML 1.0 incorporates all of them. I think that that made sense for XML >1.0, in order to be SGML compatible, but for future versions I would >rather see the first three completely separate from the fourth. The reason >I feel that the last should be separated is that the types of validation >(or "verification") that people have to do can be quite varied. XML made >the DTD optional for this reason. I don't see that making the XML >specification substantially larger with an alternative encoding for DTDs >can really make that specification simpler. > >> Why on earth would I >> want to keep multiple sets of document descriptions (schemas, whatever) around >> that share the task of defining the same document set? It seems like a >> management mess, a processing mess, a waste of bandwidth and storage because >> of redundant information, and just generally a nuisance. >> >> Making DTDs extensible is a good way, in my view, to address this issue, and >> several others. > >That sounds attractive, and I encourage you to try and make it work. If >you succeed, I will be happy to use it. But, to be honest, I don't think >it will succeed. It's like in the early days of computer programming when >people thought that it was possible to invent a single, "extensible" >programming language (or "meta programming language") that would serve all >needs. Every attempt didn't quite do everything that everybody needed, and >the harder people worked to make languages "extensible", the more complex >(C++) or merely unpopular (Lisp) the language became. > >I personally don't believe that one extensible schema/DTD language can >serve all of our diverse validation needs. The set of "extensions" will be >unlimited and approach the complexity of a full programming language. Look >at RDF schemata. They are miles and miles away from DTDs. I've had >document types where I was modeling OO systems and wanted to verify things >like "base class is not inherited more than once." Some OO-modeling schema >language would handle that, but DTDs (even extensible ones) could never do >so. > >I tend to think that a strategy that is more likely to be successful is >one that layers schema languages. At the bottom level you have something >like XML DTDs without all of the stuff related to entities and notations >(in XML element notation). That layer might include data type validation. >In levels above that you have RDF and other schemata that are more >interested in relationships than in positional occurrence. > >It seems like you are interested in that bottom layer schema. I think that >it would be good to formalize an XML element notation for the bottom >layer. But if you try to make it a replacement for DTDs, then it must do >everything that DTDs do and inherit all of the problems that the >conflation of features in DTDs causes. > >> What's so difficult about that? I can't think of any good reason (besides >> SGML compatibility) to oppose either of those goals. > >It is quite likely that SGML will soon be changed to allow you to use >whatever notation you want for XML DTDs. SGML compatibility is not a >problem. The question is what is the right design. You can make a slightly >better version of a bad design, or you can try to start again with a good >design. > >Let me ask this plainly: > >Does it make sense > >a) that textual substitutions should be specified in a part of a document >called a "document type definition". > >b) that the "document type definition" should also be responsible for >declaring media types and attaching them to non-XML entities. > >c) that the language for verifying element and attribute occurrence must >be in the same specification (XML 1.x) as that for creating elements and >attributes themselves? > >I don't think that those three things (among others) make sense anymore. >Hence, I don't think that inventing a new notation for this inappropriate >concept is a good idea. If we are to replace DTDs, let us replace them >with something simpler and more specific to the task of validation, >instead of transliterating them into another syntax, warts and all. > >Paul Prescod - http://itrc.uwaterloo.ca/~papresco > >"A writer is also a citizen, a political animal, whether he likes it or >not. But I do not accept that a writer has a greater obligation >to society than a musician or a mason or a teacher. Everyone has >a citizen's commitment." - Wole Soyinka, Africa's first Nobel Laureate > >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...) > > 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