[Home] [By Thread] [By Date] [Recent Entries]
I think the conflict is caused by the concept of a valid document as opposed to parsing according to a DTD. Validity introduced a useful concept, but perhaps we should divorce it from parsing. A 'valid' document meets the requirements of a DTD. When we talk about not needing to validate a document, we are assuming that it has already been validated when it was created so why waste the time doing it again. Perhaps another way to view it is to say that a document has been certified against a particular specification. Currrently, this specification is a DTD. But what if the specification were more abstract, say a URI? As with namespaces, there may be an agreed DTD associated with the URI (the agreement is human convention) or the specification could be non-DTD based (this document conforms to IRS/1999/ScheduleD). Applications that produce or consume documents may use DTDs or any other form to describe agreed structure. This would separate validity from parsing according to a DTD - validity is certification of conformance to whatever a URI has been agreed to represent. Validity is then not a method of parsing but a certificate of conformance. Marc B McDonald Principal Software Scientist Design Intelligence, Inc www.design-intelligence.com ---------- From: Tim Bray [SMTP:tbray@t...] Sent: Friday, March 26, 1999 9:52 AM To: James Robertson; XML Developers' List Subject: RE: XML and (K)Office At 09:20 AM 3/26/99 +1000, James Robertson wrote: >Without the rigour of a DTD, we've got nothing. This sentiment is not universally shared. While DTDs are extremely useful and should be constructed as (a small) part of any serious language-design effort, they are in some cases unnecessary (for validation, full-text indexing, and lots of other things) and in other cases insufficient - DTD validation never comes close to real business-logic validation. I am near-schizophrenic these days, running around telling people that yes, they should use DTDs, and simultaneously warning them that there are situations where they fail to be either necessary or sufficient; the kind of mystico- religious attitude above does not help. >How will future users make sense of the format without >a DTD? And what, pray tell, part of a DTD helps you "make sense" of a format? -Tim 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/ and on CD-ROM/ISBN 981-02-3594-1 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/ and on CD-ROM/ISBN 981-02-3594-1 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...)
|

Cart



