Re: Inclusion loops

The assumption that two resources are equivalent if they have the same
URI is basic.
-----Original Message-----
From: Robin Berjon <robin@knowscape.com>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Thursday, May 25, 2000 1:46 AM
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.

What do you mean by that?  Why? The same URI always by definition
identifies the same resource.  Normally that is represented by the
same set of bits, unless a document has changed.

There are some pathalogical cases like a "random" page which
deferences for fun to a random  <cynic>one of our sponsors'</cynic>
web page.  But generally this holds, so I can't imagine
an xinclude scenario where you could want to reference
the same document recursively without danger.  The xinclude does not
as  far as I know pass parameters which would allow recusion to be
conditional.

It is easy, of course, to think of infinite documents composed of
xincludes.

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


One has the choice which URIs one references.
One does not need to reference URIs which will dereference to something
misleading.
You can alwasy use a mid: which refers to a single unalterable email
message.

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

This is reasonable.

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

Those are not absolute URIs which was what was said above.
You mean
generate-id(document("http://example.com/foo.xml"))=generate-id(document("ht
tp://example.com/foo.xml"))

or if you are working just within the filespace on one system
You mean
generate-id(document("file:////usr/robin/foo.xml"))=generate-id(document("fi
le:///usr/robin/foo.xml"))

>I browsed around the W3 site looking for general directives regarding URIs
>and XML, but found little or none.

Mostly, the specifications are independent.  URIs have to work the same way
independent of the language which uses them for reference.

>Maybe I'm missing something, but the
>potential for problems seem sufficient that this would need to be
addressed.


I don't know what specific scenario you are thiking of.

>Hoping I'm not totally off,
>
>
>
>.Robin
>Critic, n.: A person who boasts himself hard to please because nobody tries
>to please him.


timbl

Received on Thursday, 25 May 2000 19:32:08 UTC