W3C home > Mailing lists > Public > www-forms-editor@w3.org > October 2007

RE: 7.8.8 (PR#145)

From: Michael Kay <mike@saxonica.com>
Date: Wed, 24 Oct 2007 10:35:48 +0100
To: "'John Boyer'" <xforms-issues@mn.aptest.com>
Cc: <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org>
Message-ID: <011201c81621$42b79b00$6501a8c0@turtle>

Thanks for the thoughtful answer.

I wasn't really concerned about stability of the environment across
different XPath evaluations: I was thinking of stability within a single
evaluation, for example the semantics of an expression such as

for $i in 1 to 20 return random()

The other functions that you mention have an explicit and formalized
dependency on the dynamic context, which is either invariant for the
evaluation of an XPath expression, or changes in a well-defined way (as with
the context item, position, and size inside a predicate). This is not the
case for your proposed random() function, and I can see implementations
having considerable difficulty with expressions such as the one above:
essentially, optimizers will have to special-case it, which means it may not
be possible to implement it without changes to the core of the XPath engine.

It's possible that in future the work on XQuery scripting extensions may be
able to formalize the semantics of functions that have side-effects, but I
think it would be unwise to anticipate that work for the sake of one
function.

I think you would be better off providing a function that returns a sequence
of random numbers, along the lines of exslt:random(), defined here:

http://www.exslt.org/random/index.html

That function was designed after informed discussion of these issues in the
community.

Michael Kay
http://www.saxonica.com/ 


> -----Original Message-----
> From: John Boyer [mailto:xforms-issues@mn.aptest.com] 
> Sent: 24 October 2007 05:52
> To: mike@saxonica.com
> Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
> Subject: 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 09:36:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 June 2009 18:12:16 GMT