[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] Re: determining ID-ness in XML
- From: David Carlisle <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 06 Nov 2001 11:30:06 +0000 (GMT)
> 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:
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"
> So why not this: http://www.foo.com#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
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
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
and . = 'foo']]
or perhaps extend it a bit to make the local-name test case
and . = 'foo']]
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.
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.