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

Re: [Sax-devel] XInclude and SAX Incompatibility


sax xinclude

> >(1) When attributes with references to unparsed entities or notations
are
> >encountered in included documents, these unparsed entities and notations
> >must be added to the [unparsed entities] and [notations] properties of
the
> >document information item, as defined in the XML Infoset specification
[2],

> Actually no. That's a may, not a must. XInclude implementations are
> not required to support notation and unparsed entity information
> items/properties.

Hmmmm... in the XInclude spec (at http://www.w3.org/TR/xinclude/) it says
in section 4.5.1:

"Any unparsed entity information item appearing in the [references]
property
of an attribute on the included items or any descendant thereof is added to
the [unparsed entities]
property of the source infoset's document information item, if it is not a
duplicate of an
existing member."

While I agree that it doesn't say "must", I do not see any allowance for
this to be optional, either.  Are you certain?

> >(2) The XInclude spec allows document fragments to be included using
> >XPointer [4] paths.  These create lots of problems with stream-based
> >processing.  For instance, an XML document could include a fragment of
> >itself which has already been processed, and unless the document stream
can
> >be re-opened and reparsed, that information is not available.

> Yes, that's tricky. In general however, I would claim it is possible
> to reopen and reparse a stream in this circumstance. You can only
> point to the stream with an XPointer if it has a URL. Given that it
> has a URL you can open it. The content at the URL may be time varying
> but that it is not an issue unique to streaming implementations of
> XInclude.

I'm envisioning the scenario when no URL is given (href="
#fragment-identifier").  This would be resolved against the current
document.  And the current document might not necessarily be able to be
reopened, if it is coming from an input stream other than a regular file.

> No, I don't think SAX needs to change. Given the very limited use of
> unparsed entities and notations in the community today, I think
> simply omitting them from the subset of the infoset that is handled
> is fully adequate for almost all practical purposes.

I agree that these issues are edge cases, and an implementation can be made
that works most of the time.  But still, it remains that issues exist which
prevent full compliance with XInclude.  I'm bringing this up here to see
what people's thoughts are about having a fully compliant XInclude
implementation for SAX.

Cheers,
Peter McCracken


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.