Re: [xml-dev] Re: determining ID-ness in XML

[David Carlisle <davidc@nag.co.uk>]

> but the preceding discussion seems
> to have been primarily about unique identifiers: IDs (or things that
> are not IDs but are unique).

I'm not sure. I don't think everyone has always agreed what for example
xml:id is supposed to mean (see for example the side discussion about
whether you would or would not be able to declare the xml:id attribute
in a DTD as something other than ID)

> [But I'll still (doggedly) assert that being able to define an attribute
> as being a cross-reference (to a unique id or no) is as useful a
> feature as being able to define a unique id. 

Can you expand on that (actually I can't see many uses for that in general
at all). In a typical case the aplication must be reading some known
xml language (xlink or xhtml <a> or whatever it is) and so knows what's
a cross ref. The problem is knowing, once you've got your xref, to what
is it supposed to be referring.


> > (This is like the xpath id() function, which does not require unique ids.)

> I thought it did require uniqueness:
nope.

well it does require uniqueness, but not by requiring that a given value
only occurs once in an ID attribute, but by declaring that the later
ones don't count:

  5.2.1 Unique IDs 
  An element node may have a unique identifier (ID). This
  is the value of the attribute that is declared in the DTD as type ID. No
  two elements in a document may have the same unique ID. If an XML
  processor reports two elements in a document as having the same unique
  ID (which is possible only if the document is invalid) then the second
  element in document order must be treated as not having a unique ID.

The end result is that if a document gets past a non validating parser
to the Xpath processor with two ID attributes with the same value, Xpath
will silently ignore the second.


> "The id function selects elements by their unique ID"
> http://www.w3.org/TR/xpath#function-id




> So why not this: http://www.foo.com#foo=bar 
or even
http://www.foo.com#xpointer(//*[@foo='bar'])

well there is one advantage in making the `plain' #foo work, apart from
it being easier to type.

If the entity that gets served by

http://www.foo.com

depends on the client making the request (xml for IE6 and HTML for
everything else, to give a typical example) then the meaning of #foo

in 

http://www.foo.com#foo

depends on the mime type of the document returned.

#foo has a meaning for text/html it would be nice if you could arrange
that the same uri-reference located a more or less equivalent thing if
something of type application/xml was returned. If the fragment ID
syntax for application/xml is different (#id=foo in your suggested
syntax) then you can't have a single uri reference that works
regardless of the mime type returned.

Personally I'd be happy with th xpath definition of #foo as posted
earlier


id('foo')|/*[not(id('foo'))]/descendant-or-self::*[@*[local-name()='id'
and . = 'foo']][1]

or perhaps extend it a bit to make the local-name test case
insensititive


id('foo')|/*[not(id('foo'))]/descendant-or-self::*[@*[
 translate(local-name(),'ID',id')='id'
and . = 'foo']][1]

Of course this looks a bit horrible (especially as XPath 1 does not have
an if-expression) but it is only a specification, it doesn't necessarily
have to be implemented that way. As this would effectively be an
extension to Xpointer, defining it in terms of Xpath seems natural, if
not particularly readable.

David


_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.