W3C home > Mailing lists > Public > uri@w3.org > September 2000

Re: FYI -- draft ietf uri doc

From: Al Gilman <asgilman@iamdigex.net>
Date: Sun, 10 Sep 2000 12:03:37 -0400
Message-Id: <Version.32.20000908212958.044e9ae0@pop.iamdigex.net>
To: uri@w3.org
At 06:13 PM 2000-09-08 -0400, Leslie Daigle wrote:
>Having sat back and watched for a while... there are at least 3 valid 
>threads that I see:
>	. is there a general statement that can be made about
>	  what a URI refers to (like the 'C' pointer confusion) --
>	  is it the box, the contents of the box, the location 
>	  where the box is if it in fact exists?
>	. are there useful mechanisms for expressing relationships
>	  between resources, or between identifiers?  (a really
>	  crude attempt at distilling Dan Laliberte's thoughtful 
>	  comments).
>	. irrespective of whether the resource is the box, its
>	  contents, or whatever, what are the services that
>	  can make use of the identifier/work on the resource
>	  (beyond the traditional, bald, "get").
>I think these are all valid and important issues in need of discussion.
>But, at least the last 2 are outside the realm of the URI
>specification itself (as it stands today, and many of us believe
>it's best handled outside the identifier spec), 

Many of us believe it's best handled outside the identifier spec and some
of us have been told it has to be solved outside the XML spec.  Therein
lies a genuine problem. Until there is a better mutual agreement on how,
end-to-end, it can and should be solved, the URI community should be
supporting the investigation of avenues of relief.  We can't just blow this

The record of the xml-uri@w3.org discussions
<http://lists.w3.org/Archives/Public/xml-uri/> demonstrates, as I see it,
that there is an integration problem between XML and URIs.

The example that I would offer to suggest that there is an actual problem
is the following:

How to reference a schema or other higher-level language specification from
an XML document instance is an open issue.

There is a concept that inter-document references shall be by URI and any
referential structure employing URIs shall accept any URI.  The 'URI' in
"use a URI to identify the other resource" is an atomic notion, brooking no
discrimination among sub-categories.

On the other hand, the developers of XML processors feel it is only
reasonable to expect that if processing an XML document is contingent on
comprehending some externally referenced resource, that the XML processor
has some assurance _from XML_ that it _can process_ that resource.

One could view it this way:  Hypertext grew up around the HTML <A> element
used for informative references -- "for more information you may elect to
recover..."  References to schemas where the correct processing of the
current document instance is contingent on successful processing of the
cited schema is another whole kettle of fish. It is a normative reference,
as opposed to the informative html:a reference.

It is reasonable to consider that the terms and conditions of reference for
normative references, where the referrer depends on the referred-to, should
perhaps be more restrictive than the terms and conditions of reference for
informative (see also) references.

It is an open question as to whether this problem should be solved in the
definition of a URI or if it should be solved through the ability to add
normative assertions as to referenced type to X-Link references.  But if
XML is indeed under a constraint to use "a URI, which has to be able to be
any old URI" to refer to the schema the more restrictive terms of reference
have to come from the URI and not the XML.  But that is not necessarily a
given.  We have a problem.  We haven't got an agreement on an answser.


>and I don't see
>any specific proposals of text that could be added to the URI
>doc I circulated last week.
>"Reality with a delicate splash of the imaginary... 
>    ... or was that the other way around?"
>   -- ThinkingCat
>Leslie Daigle
Received on Sunday, 10 September 2000 11:47:15 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:38 UTC