[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XInclude vs SAX vs validation

  • From: David Brownell <david-b@p...>
  • To: Elliotte Rusty Harold <elharo@m...>, xml-dev@l...
  • Date: Tue, 21 Aug 2001 11:09:34 -0700

sax vs sax2
> 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




PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.