Re: 7.8.8 (PR#145)

Hi Michael,

The working group recognizes that there is a bit of a backlog of expectations
about XPath, particularly in light of its use within XSLT.  Strictly speaking,
there is nothing in the XPath 1.0 recommendation to suggest that extension
functions are unable to rely on sources of information other than explicit
parameters, and of course the implicit parameter of the data model containing
the context node.

As a result, the issue extends beyond the particular function mentioned in your
comment.  The same issue exists for other functions new to XForms 1.1 including
the local-date(), local-dateTime(), context() and event() functions, but also,
crucially, functions such as now(), instance(), index() and property() in 1.0. 
The 1.0 functions in particular have proven that XForms processors are able to
implement functions of this type, a necessary component for exiting CR.   The
new functions in 1.1, including the one you mentioned, do not extend the use of
XPath in a fundamentally new way beyond the XForms 1.0 recommendation.

Perhaps of equal importance, XForms is a document format that is capable of
containing both XPath expressions that operate over instance data and also
performing mutations of the instance data.  Because a mutation can occur between
virtually any two successive XPath evaluations, it happens that the types of
optimizations you mentioned below are not possible for XForms.  Put another way,
XPath functions do indeed rely on another data source not expressed in their
parameters:  the document data model.  Other language consumers of XPath may
hold constant the input document data model, so that it appears that functions
are only dependent on their parameters.  But in XForms, the data must be "filled
in" by the user, so mutation of the document data model is unavoidable.  As a
result, functions like id(), last(), count(), position() and even simple name
tests are subject to change from one evaluation of a given XPath expression to
the next.

For these reasons, the working group resolved to retain the functions defined in
both XForms 1.0 and XForms 1.1.  As well, we do agree that it is necessary to
have discussions with the XQuery group to gain a better understanding of how
classic XPath optimization techniques are affected by issues like document
mutation in XForms.   In fact, one might regard our work on dependency lists and
the master dependency digraph that drives recalculation as examples of
optimizations that might be more broadly applicable than just to XForms.

Thank you for your consideration of XForms.

Best regards,
John Boyer

> 
> 
> 
>     J. The random() function poses semantic problems because it is not
>     a pure function. Users of this function will have expectations, for
>     example that the function call will not be moved out of a
>     predicate, which the XPath formal semantics cannot guarantee.
> 
>     Functions that depend on anything beyond their parameters don't fit
>     the design of XPath.
> 
>     This is a hard area. We're quite willing to work with you on
>     designing this. (: We note that this function is new in XForms 1.1
>     so there are no compatibility requirements here :)
> 
> 
>

Received on Wednesday, 24 October 2007 04:54:07 UTC