RE: id() function and schema types

Hi Mark,

it seems your option 1 is already what the spec. intended as section 6.1.1
of the xforms spec. in regards to the type property:

The effect of this model item property is the same as placing attribute
xsi:type on the instance data

indicating that whatever type set by the type attribute on bind is exposed
through teh infoset.

kenneth

>
> 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 20:23:32 UTC