[
Lists Home |
Date Index |
Thread Index
]
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@metalab.unc.edu
Processing XML with Java (Addison-Wesley, 2002)
http://www.cafeconleche.org/books/xmljava
http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA
|
