[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Proposal Critique - XML DTDs to XML docs

  • From: "Frank Boumphrey" <bckman@i...>
  • To: "Paul Prescod" <papresco@t...>, "Xml-Dev (E-mail)" <xml-dev@i...>
  • Date: Fri, 22 May 1998 15:03:10 -0400

c three things not inherited
>>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.


-----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
>> >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
> 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)
>> 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
>> of redundant information, and just generally a nuisance.
>> Making DTDs extensible is a good way, in my view, to address this issue,
>> 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
>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
>> 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
>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
>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...)


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.