RE: Inclusion loops

Forwarding to the XInclude comments list.

My feeling is that XInclude should not dictate a specific order for
inclusions or preclude optimizaitons such as fetching a document only once
per inclusion pass, and thus relying on the same URI returning different
results for the purpose of a inclusion invocation is an unreliable strategy.
If this is a legitimate interop concern, we should simply preclude multiple
fetches of a URI in XInclude, e.g. including a document twice or two
portions of the same document should only fetch the document once.

> -----Original Message-----
> From: Robin Berjon [mailto:robin@knowscape.com]
> Sent: Wednesday, May 24, 2000 10:48 PM
> To: xml-uri@w3.org
> Subject: Inclusion loops
> 
> 
> Hi,
> 
> I apologize if 1) the following issues have already been 
> raised -- this
> list has been pretty intense and I haven't been able to 
> follow everything,
> and the archive didn't turn out any meaningful results for my 
> searches, and
> 2) this is not directly related to namespaces, it did seem 
> germane enough
> to me.
> 
> I was reading the XInclude WD when I came accross this:
> 
> 3.2.1 Inclusion loops
> When processing nested xinclude:include elements with 
> parse="xml" , it is
> an error to include a resource that contains an 
> xinclude:include containing
> a URI reference that has already been processed in the 
> inclusion chain.
> 
> At first reading it made total sense. Most include 
> (pre)processors forbid
> inclusion of already included documents, for obvious reasons. 
> However most
> of these work with file system based inclusions, which is 
> quite different.
> That's why something bothered me about the above subsection, 
> and I had to
> go back to it.
> 
> On several subsequent calls, it is very possible for the same URI to
> dereference to several different documents. In which case, 
> one XInclude
> might wish to include an URI already included, knowing that 
> it will return
> a different document, one that eventually won't lead to a loop.
> 
> I know it's a marginal case at best, but the confusion (one URI == one
> stable resource) seems to me to be potentially dangerous.
> 
> I was turning to XSLt hoping that document() and/or 
> generate-id() might
> lead to a solution, but it seems to make the same assumption:
> 
> 12.1 Multiple Source Documents
> .../...
> Two documents are treated as the same document if they are 
> identified by
> the same URI. The URI used for the comparison is the absolute URI into
> which any relative URI was resolved and does not include any fragment
> identifier. One root node is treated as the same node as 
> another root node
> if the two nodes are from the same document. Thus, the 
> following expression
> will always be true:
> generate-id(document("foo.xml"))=generate-id(document("foo.xml"))
> 
> I browsed around the W3 site looking for general directives 
> regarding URIs
> and XML, but found little or none. Maybe I'm missing 
> something, but the
> potential for problems seem sufficient that this would need 
> to be addressed.
> 
> Hoping I'm not totally off,
> 
> 
> 
> .Robin
> Critic, n.: A person who boasts himself hard to please 
> because nobody tries
> to please him.
>

Received on Thursday, 25 May 2000 17:34:03 UTC