[Bug 6028] [F&O] fn:id is broken -- gives wrong answers for elements of type ID

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6028





--- Comment #1 from Michael Kay <mike@saxonica.com>  2008-09-05 17:03:46 ---
Personal response.

I agree the design is wrong. (I say as much in my book XSLT/XPath Programmer's
Reference 4th ed). The question is what we can now do about it.

I think that issuing an erratum to change the behaviour of the existing
function in such an incompatible way would be very damaging. Not just because
it would break existing code, but also because there would be a period of at
least three years where different implementations in active use would give
different results, and also because books (like my own) and other reference and
tutorial materials will be on sale and in use for many years and will be giving
incorrect information to users, leading to general confusion in the user
community. And because the release cycle for some products is long (up to 3
years in the case of major relational database systems), the goal that XPointer
could use an XPath implementation "out of the box" would not be achieved for
several years.

One solution might be to define a new function with the "improved" behaviour,
to exist alongside the old. This isn't ideal either, because there will still
be an interoperability problem and an education problem, but at least there
won't be a compatibility problem, and the interoperability problem will be that
some implementations accept the new function and others don't, which is a lot
better than having them return fundamentally different results.

Another softer approach might be to introduce a new way of calling the existing
function: if the supplied ID value is prefixed with "#" then the function
exhibits the new behaviour. This approach has the benefit that it makes it
easier for applications to handle the coexistence of implementations that do or
don't implement the erratum - the current specification is that if a value such
as "#D001" is passed to the function, no error is reported and nothing is
selected. So the expression

(id("#D001"),id("D001")/..)[1]

would give the desired result on both pre-and post-erratum implementations.

But of course this isn't a panacea - one aim of the function is that you can
use it to follow a link from an IDREF or IDREFS attribute, and this would
require some string manipulation to make it work.

I think we should probably see this problem with a sense of perspective. Many
users are reluctant to use id() anyway, because it only works when the input
document is validated, and because some parsers don't report IDness even when
they are performing validation. Under XSLT, many users prefer to use the key()
function. Under XQuery, they prefer to write an expression such as
//A[@id="D001"] and rely on the optimizer to use whatever indexes are
available. Even if it's broken, do we really need to fix it?


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Friday, 5 September 2008 17:04:21 UTC