Re: id() function and schema types

+1 from me on your final conclusion.

Right now in 1.0 we have an id() function inherited from XPath 1.0 that 
has no knowledge of XForms type information, nor even XML schema 
information.

For 1.1, we've had the request to add an updated id() function 
specifically to get the additional parameter behaviors that are currently 
in the 1.1 draft.

Based on the 1.1 spec material prepared, it would have been reasonable to 
assume that the new id() function would continue to ignore extra channels 
of ID
information since it is still an XPath 1.0 function and since this is how 
all of our other functions and other features work.  However, it was also 
reasonable
to assume that perhaps the new id function did have additional 
intelligence based on the reader's understandable analogy with the XPath 
2.0 function
we are modelling.  The existing spec info did not make an indication, 
which is why I added the editorial note to ask for it to be cleared up.

So, for me the quicker 1.1 solution is to add the new feature in a way 
that is consistent with existing features (which means the new id() 
function
would not understand xforms type) and then in the next xforms after 1.1 we 
already agreed to adopt XPath 2.0, which is where we have to make
the tighter integration between xpath, xforms and xml schema.

And the point after that is where calling it something other than id() 
makes a lot of sense to me so that we *don't* have the implied XPath 2.0 
semantic to deal with.

Cheers,
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Mark Birbeck" <mark.birbeck@x-port.net> 
Sent by: www-forms-request@w3.org
04/26/2006 09:37 AM

To
<www-forms@w3.org>
cc

Subject
id() function and schema types







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/