Lists Home |
Date Index |
- From: "Simon St.Laurent" <SimonStL@classic.msn.com>
- To: "Xml-Dev (E-mail)" <firstname.lastname@example.org>
- Date: Mon, 25 May 98 01:44:00 UT
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
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.
>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
Dynamic HTML: A Primer / XML: A Primer / Cookies
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)