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

Re: Use cases

From: Tim Berners-Lee <timbl@w3.org>
Date: Sat, 20 May 2000 19:42:04 -0400
Message-ID: <014f01bfc2b5$09203cc0$e9a55c8b@ridge.w3.org>
To: "Michael Rys" <mrys@microsoft.com>, <xml-uri@w3.org>
Tim BL
>> Convince me.  If the URIs are actually resolved then they must be valid
>> relative URIs. They must absolutize to a valid and correct absolute URI.

Michael Rys:
>All the relative URIs that our tools generate (AFAIK) are intradocument
>URIs. An example for inline schemas is:
><Schema name="Schema" xmlns="urn:schemas-microsoft-com:xml-data"

1)  This does note define #Schema unless Schema/name is of type ID. I guess
it is.

><ElementType name="customer" content="empty" model="closed">
> <AttributeType name="CustomerID" dt:type="string"/>
> <AttributeType name="CompanyName" dt:type="string"/>
> <AttributeType name="ContactName" dt:type="string"/>
> <attribute type="CustomerID"/>
> <attribute type="CompanyName"/>
> <attribute type="ContactName"/>
><customer xmlns="x-schema:#Schema" CustomerID="ALFKI" CompanyName="Alfreds

Yes, this is an absolute URI as David says.  It is has no relevance to
anything here, as
x-schema is a schem which must define some absolute meaning for the resourse
"x-schema:" which will be the same everywhere. Whatever resource it is has
better have a fragment id "#Schema".  Bt it ain't this document.
URIs are universal: absolute ones must mean the same everywhere. (yes,
file:/// is a known and designed and documented bug).

>Futterkiste" ContactName="Maria Anders" />
>Here the customer element refers to the schema with the name Schema that is
>local to the document. So in this case (disregarding copies),
>or not does not make a difference. However, as soon as I make a copy to a
>different server, absolutization will change the identity of the namespace.
>Now assume that people author their inline schemas such that they use
>inline schema names. For example, the customer schema is called
>CustomerSchema, the publication schema is called PubSchema etc. For some
>reason, these schemas are always provided inline but it is understood, that
>the names of two CustomerSchema::Customer elements from different document
>instances have to be considered to be the same. This is possible with the
>current reading of literal string equality , it will break if we require
>absolutization (since the two elements are located in two different
>documents, their absolute URI will always differ).
>Since this is perfectly legal according to the current namespace spec, we
>would break anybody that was using a naming scheme as described in this
>example. I do not think that this acceptable without giving clear
>alternatives and a long enough transition period.
>> If comparing the relative URIs didn't give misleading
>> results, comparing the
>> absolute URIs certainly won't.
>See scenario above.
>> > While we as tool implementers have control
>> >over the tools we write, we do not have control over our customers'
>> >documents.
>> However, I would expect your customer to use relative URIs in the normal
>> spec-consistent way rather than try to construct tortured proofs by
>> which we have had on this list.
>I don't quite understand this statement. Our customers that understand the
>namespace spec are well aware of the basic difference between name equality
>(literal) and schema resolution (fetching a resource).
>> >In general retroactive spec changes would be acceptable "if possible",
>> >namely:
>> >
>> >1. retroactive changes have virtually no impact on the conformance of
>> >existing documents (e.g. loosen constraints, not tighten),
>> I would suggest that anything which passed well-formedness before
>> and fails after was bound to fail at a later date anyway when
>> dereferencing occurred.
>I do not understand this statement either (I guess, I am just too
>jetlagged). Any document that currently is parsed and even validated using
>inline schemas, will continue to do so. I do not see this as a problem. The
>problem is that some of these documents are used with applications (e.g.,
>DOM based applications) that perform comparison of namespace-qualified
>and assume a literal interpretation of the namespaceuri. If this is
>the documents that use relative namespaceuris will not conform to the
>assumptions made by these applications (and the guarantees given by the
>namespace 1.0 spec), their information content will change and data will
>break the applications based on the new DOM behaviour.
>> >2. retroactive changes can be introduced by vendors with minimal
>> >disruption,
>> That I would think would be the case. Much larger changes
>> have been made.
>The problem is really that we write tools and not their complete
>applications. All customer applications that use the DOM and the customer
>documents are outside of our control.
>> >3. that changes larger than these employ a versioning mechanism,
>That a new version of the spec may be ok (subject to point 4).
>> >4. that a new version have compelling feature benefits to drive adoption
>> >vendors and customers.
>> We are talking about a move to the way Microsoft customers have been
>> using relative URIs in other contexts for years. This would IMHO go under
>> the heading of bug fix rather than new feature.
>Please note that the current namespace spec uses namespaceuris to determine
>equality of names - nothing more and nothing less. In addition, by using
>uris, it allows for certain applications/processors that are layered on top
>of the namespaces (such as schema), to retrieve resources at the namespace
>uri that provide semantics to the namespace. These are in principle two
>orthogonal concepts (you could define name equality based on the provided
>semantics, an expensive undertaking in the general case, or you could
>semantics with other mechanisms than namespace uris). I do not see, why
>changing the name equality definition can be considered a bug fix. In my
>opinion, it more looks like a design change request...

>> >In the specific case being considered, none of these conditions appear
>> >obtain, and thus changes to the NS recommendation should not be
>> >as a possible option.
>> Your current software is quite inconsistent in that it uses
>> them as relative URIs at one moment and strings the next.
>No. It layers. Basic name equality is decoupled from the schema resolution
>interpretation of certain namespaceuris. There may have been better
>mechanisms to do the later (I was not there, when the decision was made to
>utilize namespace uris for schema references), but the mechanism is not
>inconsistent and follows the letter and a reasonable interpretation of the
>namespace spec.

No, it breaks, I think. Check the example in
You can talk about separating layers, but if you iuse the URIs of real
(I know there are people who hate that idea, but there are others who don't)
then you get incorrect behaviour.

>> In fact, it only runs
>> because none of your users have tried the rather obscure test cases which
>> been generated to show this inconsistency. But one day they will. One
>> document will fail a well-formedness test even though it has been quite
>> constructed with pointers to completely valid URIs of real schemas.  Two
>> namespaces will have different URIs but happen to be declared in contexts
>such that
>> the relative URIs are in fact the same. The two namespaces will have to
>happen to
>> have attributes of the same name and some actual instance will have to
>happen to
>> validly use both attributes on the same element.  I bet it hasn't
>> yet.
>I am confused about your well-formedness remark. If documents are not
>well-formed, they will not parse, period.

But in fact the user meant the namespaces to be different, and they should
have parsed.

>This scenario is the main scenario why I think that relative namespace URIs
>should be discouraged (but not forbidden) for the purpose of defining
>namescoping. However, that problem can also happen with absolute namespace
>URI that are not globally unique (e.g., file://localhost/foo).


>If two relative schema references in different documents are refering to
>different inline schemas that have the same name, e.g., Schema in both
>documents, then the above can happen. The current namespace spec addresses
>this problem when referring to the definition of namespace uris that they
>should be distinct if used for name referencing. People have a workaround,
>do not rely on arbitrary relative URIs (or non globally unique absolute
>URIs) for name equivalence. Either use globally-unique absolute uris or to
>take extra care in your naming of relative URIs.
>> But one day. The document will fail the
>> well-formedness test though quite valid. That will be a bug.
>> If you don't fix it now then you will have to explain this
>> problem in great detail
>> to your poor users, or just explain that there is a bug when using
>> URIs sometimes.
>Currently, this is not a bug, this is according to spec.

I will remember that. Not a bug according to the spec.
Then they really are not URIs.
Then we would have to change hte NS spec to say that htey are strings.

>Best regards
>PS: Tim, feel free to contact me in Amsterdam for a direct discussion (I
>will be giving a talk tomorrow in the Web Publishing track).
Received on Saturday, 20 May 2000 19:40:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:58 UTC