XML and (K)Office

[Marc.McDonald at Design-Intelligence.com]

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 at textuality.com]
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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following 
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)