locator syntax, resources, etc.

Paul Grosso suggests deleting all locator syntax discussion from the
working draft.

I agree that there is no reason for that syntax to be there, but I think
that we do need to talk more about locators because we need to define
formally and finally what it is that they locate.

It is not the case that the things addressed by XPointers are resources.
If they were resources, they would have URIs and not "URI references."
They are, at best, sub-resources. Unfortunately the word sub-resource is
not well-defined.

"Sub-resource" certainly is not defined in "Uniform Resource Identifiers
(URI): Generic Syntax". It talks only of "fragments" and "fragment
identifiers." The semantics of the fragment identifier syntax are left
entirely up to the reader. It is not even necessarily the case that they
identify addressable objects. One could imagine a fragment identifier that
says what stylesheet to use or (in the SMIL case) what seconds of a movie
to show. In other words, a fragment identifier could describe behavior
instead of describing a location. It is arguably the case that HTML
fragment identifiers are most often used for describing behavior not a
location. 

Are we really going to allow XLinks to resources like:

http://my.media.com/myMedia.mxl#show_with_blue_background() ? And should
such a link be recorded in the big book of links as semantically different
than a link to http://my.media.com/myMedia.mxl#show_with_red_background()
?

I propose that we restrict the set of useful fragment identifiers to those
that address objects or lists of objects. The definition of "object" is
"item defined by an information set."

RDF abolishes the words "sub-resource" and "fragment". It treats resource
as if it encompassed both resources and sub-resources. It says: "A
resource may be a part of a Web page; e.g. a specific HTML or XML element
within the document source." This is clearly not what the URI RFC says.
RDF also uses the term "anchor id" where URI uses the term "fragment id". 

In other words, RDF ignores the fact that the word fragment is not defined
and in general uses terminology that does not come from the URI
specification. RDF and XLink should use the same definition for
addressable objects but it is too late to fix RDF.

RDF would, in fact, allow properties to be assigned to
show_with_blue_background() versus show_with_red_background() even if the
creators of those fragment identifiers did not intend them to be separate
objects. This example is fanciful but there are real-world ones also:
XPointer's range does not define an object or object list in an
information set. The proposed SMIL second identifier has the same problem
unless there is one day a SMIL information set where seconds are nodes.

To make this concrete, imagine that you are using XSL or your favorite
stylesheet language. You invoke a method called "GetXLinkAnchors()". What
do you get back? A list of *what*? I claim that it should be a list of
nodes. It should not be possible to claim to link to things that do not
have a concept of node because it isn't logically possible to link to
something that doesn't have a well-defined concept of identity.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"The new revolutionaries believe the time has come for an aggressive 
move against our oppressors. We have established a solid beachhead 
on Friday. We now intend to fight vigorously for 'casual Thursdays.'
  -- who says America's revolutionary spirit is dead?

Received on Tuesday, 29 June 1999 14:58:58 UTC