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

Re: [Sax-devel] XInclude and SAX Incompatibility

• To: "Peter McCracken" <peterjm@c...>
• Subject: Re: [Sax-devel] XInclude and SAX Incompatibility
• From: Elliotte Rusty Harold <elharo@m...>
• Date: Tue, 24 Jun 2003 21:07:44 -0400
• Cc: sax-devel@l..., xml-dev@l...
• In-reply-to: <OFADB10D5A.7AC22BE9-ON85256D4F.006BE8DD@t...>
• References: <OFADB10D5A.7AC22BE9-ON85256D4F.006BE8DD@t...>

At 4:03 PM -0400 6/24/03, Peter McCracken wrote:

>"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?

Yes. See section 5.3. There need not be any unparsed entity 
information items in the infoset. The section you describe merely 
indicates what should happen if they are present.

>>  >(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.
>

That's not legal. According to section 5.3 all element and document 
information items *must* have base URI properties, against which a 
relative URL can be resolved.

>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.

This is backwards. If this is important to you, bring it up with the 
XInclude working group, and insist that they make a fully SAX 
compatible version of XInclude. I suspect you'll find they think they 
already have.
-- 

   Elliotte Rusty Harold
   elharo@m...
   Processing XML with Java (Addison-Wesley, 2002)
   http://www.cafeconleche.org/books/xmljava
   http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA

• Follow-Ups:
  • Re: Re: [Sax-devel] XInclude and SAX Incompatibility
    • From: Richard Tobin <richard@c...>
  • Re: Re: [Sax-devel] XInclude and SAX Incompatibility
    • From: Oleg Tkachenko <olegt@m...>

• References:
  • Re: [Sax-devel] XInclude and SAX Incompatibility
    • From: "Peter McCracken" <peterjm@c...>

• Prev by Date: Re: [Sax-devel] XInclude and SAX Incompatibility
• Next by Date: xml data mining
• Previous by thread: Re: [Sax-devel] XInclude and SAX Incompatibility
• Next by thread: Re: Re: [Sax-devel] XInclude and SAX Incompatibility
• Index(es):
  • Date
  • Thread