W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Re: Inclusions and other gotchas (was:Re: inclusion)

From: Paul Grosso <pgrosso@arbortext.com>
Date: Fri, 26 May 2000 12:46:54 -0500
Message-Id: <3.0.32.20000526124639.00691248@pophost.arbortext.com>
To: xml-uri@w3.org
At 13:08 2000 05 26 -0500, Al Gilman wrote:
>At 12:00 PM 2000-05-26 -0400, John Cowan wrote:
>>Nobody in this debate wants to go past that point, except in strawman mode
>>(not "trial balloon", but the original sense of "strawman": a caricature
>>of your opponent's position, created for the purpose of demolishing it).
>>If the URIs are string-equal, the namespaces are equal.  However, if
>>the URI *references* are string-equal, must the namespaces be equal also?
>>
>>	"Absolutizing" position: no.
>>	"Literal" position: yes.
>>	"Forbid" position: MU (let's unask the question, and make sure
>>		it can't be asked any more).
>
>OK, now I'm confused. 

Oh geez.  I thought JohnC's statements above were about the least
confusing thing written on this mailing list in the last week!

> Is there a layering/procrastination approach or not?
>
>Is there a case where literal comparison of _two ns-attr values occurring
>in the same document_ will find them the same whereas abolutizing as
>URI-references per URI RFC will determine them to be different?
>
>I may have missed that case.

What do I have to DO!!!!!  I've posted this case 2 or 3 times, and
I know my email is going out!  See:
http://lists.w3.org/Archives/Public/xml-uri/2000May/0056

The example again is:

http://example.com/file.xml
---------------------------
<doc xml:base="http://example.com/" xmlns:y="foo">
 <elem1 xml:base="./bar/">
  <x:E xmlns:x="../foo" xmlns:z="foo">
    <elem2 x:a="1" y:a="2" z:a="3"/>
  </x:E>
 </elem1>
</doc>

The namespace names associated with the prefixes y and z in the
example above will be the same with the literal string interpretation,
but different if the relative URI refs are absolutized.

paul
Received on Friday, 26 May 2000 13:46:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC