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: XInclude vs SAX vs validation



> That's not been my experience. Comment nodes are much more painful to handle in 
> SAX than DOM, and the infoset requires them so XInclude requires them.

Infoset doesn't "require" that!  That requirement seems to have come down
the XPointer/XPath trail.  The pain is only that a somewhat awkward layering
model ("properties") was used for something that's proven to be widely used.


>     Comments
> inside xinclude:include elements are particularly nasty because they have to be treated
> differently than comments outside of such elements. However, from inside the 
> LexicalHandler it's hard to tell whether or not you're inside an xinclude:include element.

Hmm, I guess it mostly depends on how you implement that.
Seems like a boolean flag should suffice, depending on how
you pass on the info items from the XIncluded document.
(That's how I'd do it...)


> I'm wondering if for Infoset compatibility it's time to add the comment() method to the
> ContentHandler class and require parsers to report comments. This could be done in
> a compatible fashion by subclassing ContentHandler with ContentHandler3 that adds
> the comment() method currently in LexicalHandler. 

Taking that approach to Infoset support leads to:

    interface ContentHandlerXX extends ContentHandler, DTDHandler,
        DeclHandler, LexicalHandler {}

as well as the other three changes I listed a while back:  exposing "standalone",
more Locator/entity information, and per-attribute isSpecified info.  I don't
like that approach enough to sell it (most folk don't want to get at everything
in the infoset, it's not "Simple"), but tastes vary.


> Also not having the base URI of the original document available as a SAX property is
> annoying. Is this on the list of things to add in SAX3? 

It's already part of SAX2:  Locator.getSystemId(), called at appropriate moments,
provides that information.  "Appropriate" certainly includes the first startElement(),
and any callback before (and including!) startDTD().  No change necessary, so
long as that URI is actually available to the parser.

So far I've seen nothing that'd call for a "major" revision of SAX2; things can be
layered without sacrificing backward compatibility.

- Dave