OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] Parser structure (historical background question)

> I'm curious how it came about that (at least for SAX) validation was 
> incorporated into the parser.

I think that's how the first couple parsers did it.  Remember that until
the SAX2 extensions were defined, there was no standard API to
get at the declarations in the DTD ("root element is foo", and so on).

>     It'd seem to make a lot more sense to have 
> it as a separate layer that works off a parse event stream. This type of 
> approach would vastly increase the flexibility (allowing validation to 
> be just another pipeline step) without substantially adding to the 
> costs, as far as I can see.
> Any comments?

I most certainly agree, having implemented that very approach
a couple years back.  I suspect you know that.  Also, I think
that Sun's "Multi-Schema Validator" does much the same for
non-DTD validation scheme such as Relax.  SAX2, with the
extensions, is pretty well suited to such an approach.

For DTDs, there are a couple technical glitches in XML that
make validation not be a clean layer.  Of course the issues all
relate to entity processing ... for PEs, bad nesting violates a
validity constraint, but for GEs it's a well formedness constraint.
(Though I'll note that XP 0.5 treated bad PE nesting as a WF
error, and I've always preferred that approach.)  It's an easy
workaround in most cases to have a "non-validating" parser
core (such as AElfred2) report validity errors for that handful
of cases.

- Dave