- 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
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 UTC