- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Wed, 26 Apr 2006 17:37:25 +0100
- To: <www-forms@w3.org>
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: <http://www.w3.org/TR/xpath20/#static_context> >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. Regards, Mark Mark Birbeck CEO 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 http://www.formsPlayer.com/
Received on Wednesday, 26 April 2006 16:38:51 UTC