OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] So maybe ID isn't a problem after all.

> I debate the value of this.... it sounds like you're trying to standardise 
> the #foo syntax across all media types?

well only because I don't know of a media type that supports fragment
identifiers for which #foo is not legal. (But I haven't done an
exhaustive or even superficial search).   I don't want to standardise
anything across _all_ but it is useful in that (unlike xpointer)
it works over more than one.

You said the fragment id thread was a read herring, but it seems to me
the main point, In most other possible uses of an identifier the
application can either know which attributes are ID already, or doesn't
care or you can use something like full Xpath/Xpointer //*[@att='val']
and extract the node without having to declare or pre-declare any

The main (One could almost say only) benefit of having identified labels
(which need not be ID in the XMl sense) within the document using some
globally known syntax is their use in fragment identifiers.
Even here if you are only concerned with XML, using xpointer with an
XPath as above is a bit more verbose and possibly a bit less efficient
but clearly workable (f you can find an Xpointer implementation)
so if it was only for XML the fact that "raw" identifiers are largely
unreliable would be a minor inconvenience but not a real problem.

But I still claim that in a world where servers like cocoon/axkit, even
IIS are doing server side transforms and sending any number of different 
mime types for the same URI, depending on the requesting client, that
it's useful to have the _possibility_ of publishing a URI reference to
within a document that works over a range of mime types. And you don't
have that possiblity unless you keep the syntax being very simple, and
in fact just a  name.

Whether any of the proposed solutions are too disruptive to be worth the
benefits is a legitimate area of debate (and I'm not sure either way, to
be honest) but you are aguing I think that there is no benefit at all
which is where we disagree.


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.