RE: id() function and schema types

Hi Nick,

> In '7.5.1 Dynamic Dependencies' of XForms 1.0 SE (
> http://www.w3.org/TR/2006/REC-xforms-20060314/index-all.html#e
> xpr-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?

Yes, I agree. What I was saying is that there are two ways to get schema
information into an XPath expression:

  * the XPath evaluator 'knows' about all elements and attributes,
    and their types, since this is part of the 'context' in which
    the XPath expression is evaluated;

  * individual functions can do some trickery to get at this
    information from other sources, such as the schema itself,
    or the XForms processor's MIP type values.

The first is nice and generic, but will only exist in XPath 2.0. The second
is open to both XPath 1.0 and 2.0, since it involves some kind of 'behind
the scenes' wizardry on the part of the processor.

My suggestion was not that we don't make use of the schema information for
an id() function, but that we don't pretend it is the same id()-like
function as the one in XPath 2.0. The reason is quite simply that the
genuine article (the XPath 2.0 function) can find out about ID types due to
context; our poor man's version (using XPath 1.0) will have to get hold of
the XForms data types 'round the back'.

To put this another way you can also look at where the function might be
implemented. If you had an XPath 2.0 processor, then all you need to do is
set the evaluation context and run a query that includes id(); as long as
you add the XForms MIP type values to the context before you make the call,
you'll be fine. The id() function can therefore sit in the XPath module
since it will need nothing more than the context information to do its work.

However, with XPath 1.0 this won't work since the id()-like function needs
access to the XForms data structures to get the MIP types. Therefore, unless
you want to pollute your XPath evaluator with 'knowledge' of XForms, you'd
need to implement the id()-like function over on the *XForms processor* and
make a call to it from the XPath evaluator. The XPath evaluator doesn't care
what the id()-like function does internally, as long as it gives back some
nodes.

Hence my preference for changing the name so that the XPath function and
this one are kept separate.

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 Thursday, 27 April 2006 09:55:51 UTC