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

Re: id() function and schema types

From: <Nick_Van_den_Bleeken@inventivedesigners.com>
Date: Thu, 27 Apr 2006 09:09:53 +0200
To: John Boyer <boyerj@ca.ibm.com>
Cc: "Mark Birbeck" <mark.birbeck@x-port.net>, www-forms@w3.org, www-forms-request@w3.org
Message-ID: <OF256A93F6.AC2347F4-ONC125715D.002452FC-C125715D.0027590B@inventivedesigners.com>

In '7.5.1 Dynamic Dependencies' of XForms 1.0 SE (
http://www.w3.org/TR/2006/REC-xforms-20060314/index-all.html#expr-dynamic-dependency) 
you can read : '... Another dynamic dependency is any use of the id() 
function, unless both the parameter to the function and the matching 
attribute of type xsd:ID are fixed.  ...' doesn't this imply that schema 
types (and specifically xsd:ID) are taken into account?

Regards,

Nick Van den Bleeken  -  Research & Development
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivedesigners.com

www-forms-request@w3.org wrote on 04/26/2006 11:01:11 PM:

> 
> +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/
> 
> 
> 



--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer
Received on Thursday, 27 April 2006 07:10:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:03 GMT