Lists Home |
Date Index |
> >(1) When attributes with references to unparsed entities or notations
> >encountered in included documents, these unparsed entities and notations
> >must be added to the [unparsed entities] and [notations] properties of
> >document information item, as defined in the XML Infoset specification
> Actually no. That's a may, not a must. XInclude implementations are
> not required to support notation and unparsed entity information
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]
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
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  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
> >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
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.