XSchemas and DTDs

[Paul Prescod]

Simon St.Laurent wrote:
> 
> This is going to be one of the 'hard' issues in the weeks to come, I fear.  I
> wish that the XML spec had discussed processors (non-validating processors,
> that is) and validation as a module on top of those processors, instead of
> describing validating processors as a single unit.  Of course, this would have
> required building the spec quite differently.

I don't see this as a complicated issue. View an XSchema processor as
merely another application.

What happens if an XHTML browser loads an XHTML document and finds out
that a URL does not conform to the URL specification? It triggers an
error. This does not affect the validity of the document -- it is just an
application error. What happens if a DSSSL or XSL stylesheet triggers an
error in the processing of a document. This doesn't affect the validity of
the document either -- it is just an application error. If a stylesheet is
a converter that converts XML documents + stylesheets to renditions of
those documents, then a schema processor is a converter that converts XML
documents + schemas to truth values. I don't think that we need to state a
relationship to DTD validation anymore than a stylesheet language does.
The DTD (if any) does "the DTD thing" (validation) and the XSchema does
verification.
 
> Non-validating processors and interfaces like SAX seem like useful starting
> points for the processing discussion, upon which we can build our
> schema-verifying layers. I'd love to see a verification implementation that
> behaves like David Megginson's XAF - using SAX to parse the document and its
> XSchema (XAF is about architectural forms), then using SAX to return the
> 'verified' document to the application above.  This kind of 'layering' seems
> like an appropriate model to me.

That's one model. In other cases, the application will want to just hand a
tree or event stream to the XSChema verifier and see if the verifies or
not. Since verification does not affect the document, you may or may not
want to invoke the penalty of re-triggering the SAX events. Only time will
tell if that is efficient enough if there are several layers of
verification.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

Three things are most perilous: Connectors that corrode
Unproven algorithms, and self-modifying code
http://www.geezjan.org/humor/computers/threes.html



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/
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)