ModSAX: Proposed Core Features (heretical?)

[Marc.McDonald at Design-Intelligence.com]

I would suggest that the application should specify the DTD that the 
document is parsed by. After all, the document is supposed to conform 
to the application so you shouldn't have the document define what it 
means to conform (i.e. the DTD to use).

Perhaps extend SAX so that there is an API to specify a DTD to 
override the documents?

Marc B McDonald
Principal Software Scientist
Design Intelligence, Inc
www.design-intelligence.com


----------
From:  Bill la Forge [SMTP:b.laforge at jxml.com]
Sent:  Monday, March 15, 1999 11:18 AM
To:  Simon St.Laurent; XML-Dev Mailing list
Subject:  Re: ModSAX: Proposed Core Features (heretical?)

From: Simon St.Laurent <simonstl at simonstl.com>
>Basically, he wanted the ability to check the document structure 
without
>the internal subset, so he could rely on the validation process to 
make
>certain that documents conformed to an 'official' DTD, without extra 
junk
>some twerpy developer put in the internal subset to make his own 
version
>valid if not official.

But even given that an 'official' DTD was used, there is a question as 
to
WHICH official DTD was used. I see several problems with relying on
an unaugmented SAX parser for validation of data being input to an 
application:

1. DTD-driven validation is rarely complete enough--there will always 
be
    something critical that the application needs to validate. 
Fortunately,
    SAX supports parse exceptions in all the right places, with full 
information
    available on where in the document the error occurred.

2. If the application is going to depend on the parser for some of the 
validation
    (a real boon to the application programmer), then the application 
needs
    to be informed by the parser as to which DTD or other schema was 
used.

    Having the document specify this information in a PI or by some 
other means is
    not sufficient unless that information is somehow compared to the 
DTD
    actually used by the parser.

3. As mentioned by Simon, allowing an author to change a DTD makes no
    sense at all in terms of providing a validation service for the 
application.

4. When filters are placed between the parser and the application, 
validation is
    best done in the last filter, rather than prior to the 
transformations performed
    by those filters. Validation by the parser in this case may 
produce clearer
    error messages, but validation of the transformed data provides 
the application
    with a greater assurance that its data will be in the expected 
form.

My belief here is that it is perhaps best to abandon validation by the 
parser-
kernel and instead use filters which support the validation needs of 
the
application. Errors so detected may be because of a poorly constructed 
document,
but may also be due to constraints imposed by a particular 
application. This
of course raises the question of how the response to these two 
different types of
errors should differ. I can understand a desire to make such a 
distinction, but
I have not yet come to appreciate the need to make such a 
distinction.

Bill



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)