W3C home > Mailing lists > Public > www-forms@w3.org > April 2006

id() function and schema types

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 26 Apr 2006 17:37:25 +0100
To: <www-forms@w3.org>
Message-ID: <011a01c6694f$b45c7990$0e01a8c0@Jan>

Hi all,

I know that we agreed on the call that Leigh is going to do some work on
this, but since I have a link to hand from some previous reading I thought I
might as well post it.

On the call I was saying that ideally the 'context' for an XPath expression
would include the schema types that are 'in-scope', and that way, using
bind/@type for things like ID or number would 'just work'.

This is in fact exactly what has been done in XPath 2.0:


>From this I can therefore see a couple of choices (there may be others):

  * we *don't* use the name id() for the function, since once
    a processor supports XPath 2.0 everything will just fall
    out nicely anyway (as it would in say, XForms 2.0 if it
    supports XPath 2.0);

  * we define that in XForms 1.1, schema information
    becomes part of the context for XPath expressions.

Although I like the second solution, I think it is not consistent with other
situations where we have actually added functions (like boolean-from-string
and the time/date calculations), or require the use of a function (like
needing to use contains() when we have a space-separated list) precisely to
get round the fact that XPath 1.0 is not schema aware).

So my vote is that we shouldn't use the name id() for this function, since
it is going to have to do some 'hackery' if it is to make use of schema
information to find ID values, when using the non-schema aware XPath 1.0.



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
Received on Wednesday, 26 April 2006 16:38:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:17 UTC