RE: Re[2]: Summary: Section 2: What does a URI identify?

Jonathan,

> -----Original Message-----
> From: Jonathan Borden [mailto:jonathan@openhealth.org]
> Sent: 19 March 2002 20:13
> To: Williams, Stuart
> Cc: Paul Grosso; www-tag@w3.org; Chris Lilley; McBride, Brian
> Subject: Re: Re[2]: Summary: Section 2: What does a URI identify?
> 
> 
> Stuart,
> 
> > I don't think the XML Base recommendation is the issue here. XML Base
gives
> > a means to specify/determine the base URI to be used when resolving a
> > relative URI. It is RFC2396 (which pre-dates the RDF recommendation)
that
> > makes '#foo' a "same document reference" and establishes that a base URI
is
> > not applied when resolving a "same document reference".
> 
> I understand the interpretation. Reading section 4.2 carefully, "...
> traversal of such a reference should not result in an additional retrieval
> action. However ...
> 
> After "However" it goes on to talk about empty URI references, but before,
> bare fragment identifiers. Given the context switches, "in other words"
and
> "howevers" it really is not clear to me that this cannot be interpreted as
> allowing an application to construct an absolute URI reference from a bare
> fragment identifier by prepending the base URI.

So the first sentence says it crisply (I think)...

   A URI reference that does not contain a URI is a reference to the
   current document.

...and I don't think that the next sentence digs the hole too deep...

   In other words, an empty URI reference within a
   document is interpreted as a reference to the start of that document,
   and a reference containing only a fragment identifier is a reference
   to the identified fragment of that document.  

The next sentence seems mostly an observation...

   Traversal of such a
   reference should not result in an additional retrieval action.

...and then we get what I suspect you regard as the problem piece, the
"However..." sentence. I'll concede that "the URI reference" referred as the
subject of the sentence could be either empty or just a fragment, and that
the remainder of the sentence only says anything definitive about an empty
URI reference. 

This leaves it completely unspecified what happens in a context where it is
known that traversal of a URI reference with just a fragment is *always*
(that was the qualifier - always) intended to result in a new request. I
don't know if the RDF circumstance that concerns you is such a circumstance
- equally I don't know that it isn't.

The piece that perhaps gives me some trouble is the "then an empty URI
reference represents the base URI of the current document" and I'm wondering
what URI is that? Is it the current base as established possibly by xml:base
within the current document or is it the base of the current document (if
those two things are indeed different).

> That is to say: while I do see the interpretation of "same document
> references" as bare fragment identifiers, I similarly see the "wiggle
room"
> that allows an application such as RDF to 'normalize' bare fragments into
> absolute URI references.

Hmmmm.... not sure I like the notion of "wiggle room". It feels like
searching for a creative interpretation of words that attempt to capture,
however imperfectly, the intent of the authors. It would be a pity if we
were to write specs. with buried subtleties. It would seem a little self
defeating :-) 

Its not clear to me what specifically (by 2396) might suggest that an
application *is* "...allowed construct an absolute URI reference from a bare
fragment identifier by prepending the base URI." 
 
> On the other hand this really really is like reading tea leaves, hence the
> need for clarification. In the process of clarification, I am stating what
I
> perceive to be the needs of a class of applications.
> 
> [...]
> >
> > However, in delving into RFC 2396, found pretty clear that '#foo' is not
a
> > relative URI reference, and hence is not resolved with respect to an XML
> > base.
> 
> It is completely clear, that "#foo" is not a relative URI, 
> rather a fragment identifier. "#foo" is pretty clearly a URI-reference 
> according to the BNF.
> All that one can conclude is that the rules of relative URI references do
> not apply. The rules for same document references seem to be 
> given in 4.2?
> 
> None of this is entirely clear to me.

I'm quite willing to be shown that I am misinterpreting 2396, or that I have
missed something that updates it.

> > Section 4.1 of RFC 2396 is also pretty clear:
> >
> >    The semantics of a fragment identifier is a property of the data
> >    resulting from a retrieval action, regardless of the type of URI used
> >    in the reference.  Therefore, the format and interpretation of
> >    fragment identifiers is dependent on the media type [RFC2046] of the
> >    retrieval result.
> 
> Yup. What, then, is the position of the TAG regarding the "semantics" of
an
> XML Namespace URI _reference_ that contains a fragment identifier? What
> about the semantics of a _bare fragment identifier_ which, err, still is a
> legal XML Namespace depite the deprecation of relative URI references...

;-)

Yes... I have always wondered why XML Namespace names were allowed to be
full URI reference (with optional fragment ids) and not restricted to URIs
(and absoulute URI's at that). My initial thoughts were that it was an
oversight... perhaps somewhere between RFC1630 which speaks about Universal
Resource Identifiers (that can include fragment IDs) and RFC2396 in which
Uniform Resource Identifiers don't have fragment IDs, but introduces the
term URI reference. That said... I've also heard it said that no... the use
of URI Reference for the names of XML Namespaces was absolutely intentional
and deliberate. However, I have yet to hear an explaination of any actual
intention.

> Again, practice as defined by widely adopted W3C Recommendations, seems to
> run counter to RFC 2396 in some cases. Should fragment identifiers be
> deprecated in XML Namespaces altogether?

Well I'd really like to know if they are allowed now by accident or design
and *if* the latter I would really like to understand the reasons for that
design choice.

> Curiouser and curioser. This all is not at all clear to me, and seems to
> have great implications.

I would agree that it is not at all clear what the right way to resolve
these things is. 

> 
> Jonathan
> 

Stuart

Received on Tuesday, 19 March 2002 19:17:43 UTC