Proposed process for DTDs in XML (Implementations)

[Simon St.Laurent]

I've divided this response into two pieces.  This one addresses potential 
implementations using SAX.

Peter Murray-Rust wrote:
>SAX and the DOM co-exist very well - I have
>had feedback in-real-life saying that SAX was exactly what they wanted and
>the DOM was too large and confusing. Similarly I can see that 'XMLDTD' (or
>whatever) could find a useful niche.

This seems like the right model, especially since I suspect the DOM is gaining 
to some extent from the experience of developers who have cut their teeth on 
SAX and are ready for more power.

>Because SAX was the first API for
>XML, David and we had to face *generic* problems that hadn't been foreseen,
>particularly Exceptions and encodings.
>[...]
>One fundamental aspect is whether there needs to be any software or
>APIs. Although theoretically SAX could have been written as an API, in
>practice it was critical that David produced an implementation as proof of
>concept. (and also for 'marketing').

I feel strongly that this project will need an implementation, though I also 
fear that I'm not a good programmer to execute it.  I'd like to see the 
implementation built on SAX if possible, to continue the tradition of openness 
it began.  I can see something like a 'validating SAX', (vSAX?) a program 
which uses the SAX API to parse a DTD (or whatever we call it) and then uses 
SAX again to parse the document, validating it against the DTD.  vSAX would 
then use the same SAX API to pass the information to the routine which called 
it in the first place.  Applications already using SAX could call vSAX without 
having to make many changes.

This may go beyond the capabilities of the event-driven model.  Building this 
project in such a way that the vSAX parser could validate documents without 
having to build an entire tree would likely warp the DTDs dramatically.  That 
could be interesting, but I suspect vSAX would have to build a tree 
internally. 

Originally, I felt that a specification with a syntax and test cases would be 
sufficient. I still suspect it should be, but an implementation would be 
useful to check the spec and provide a fundamental set of tools for 
interoperability.  My Java experience is unfortunately weak, more suited to 
the integrator's task of plugging things together (my job until recently) than 
building elegant structures. This is more than a simple integration.  I'd like 
very much to participate, but don't think I can do this myself.

Volunteers?

>It may even be that we preprocess these XDTDs to conventional
>DTDs. After all there will have to be *some* processing machinery for them,
>even if it's only an XML parser and a transformation engine.

This would be another possible and simpler implementation - a converter.  Is 
it compelling enough?

>I am assuming that part of the result will be the ability to express a DTD
>(or equivalent) in XML syntax. That means it can be held as a tree. In that
>case JUMBO (and many other tools) will naturally be able to hold the result
>in memory and to display it in a variety of ways. So, to the extent that
>that is useful, I can hopefully commit to being able to provide it.

That's another useful piece, certainly - a key step toward making this more 
usable.

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer / Cookies


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)