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

Re: id() function and schema types

From: <kenneth@sklander.net>
Date: Thu, 27 Apr 2006 14:51:35 +0200
Message-ID: <20060427145135.u53nm7sfjtw0g4oc@mail.sklander.dk>
To: John Boyer <boyerj@ca.ibm.com>
Cc: Mark Birbeck <mark.birbeck@x-port.net>, www-forms@w3.org, www-forms-request@w3.org

Since the xpath 1.0 function requires the elements it selects to be defined as
unique id's, in the xpath 1.0 spec. this is said to be done in the dtd.

I have until know assumed (even though the spec. says neither way) that if a
node is declared to be id be xforms it is matched by xpath 1.0 id() - so I do
not agree that it has no knowledge.

I am wondering how to attach a DTD to instance data, otherwise the 
function, not
being able to access type information from xforms, will make the xpath 
1.0 id()
funtion yield no result when it is used in xforms 1.0.


Quoting John Boyer <boyerj@ca.ibm.com>:

> +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
> 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 Thursday, 27 April 2006 20:23:31 UTC

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