RE: 7.8.8 (PR#145)

Hi Michael,

Could you please let us know what should be put on the final disposition 
of this comment?
Given the additional information about the XForms perspective, which 
combines mutability with a batch processing view of XPaths, was convincing 
enough that you would be willing to accept that the function in question 
presents no special burden in our case, esp. in comparison to the 
resulting ease of authoring.  Or would you prefer that we record a 
disagree result, or a formal objection result.  Could you please let us 
know by Monday since the current recorded result is 'No response' to the 
end of the thread, but I would like a more definitive setting given the 
work that has gone into this consideration.

Thank you,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





John Boyer/CanWest/IBM@IBMCA 
Sent by: www-forms-editor-request@w3.org
10/24/2007 09:21 AM

To
"Michael Kay" <mike@saxonica.com>
cc
w3c-xml-query-wg@w3.org, www-forms-editor@w3.org, 
www-forms-editor-request@w3.org, "'John Boyer'" 
<xforms-issues@mn.aptest.com>
Subject
RE: 7.8.8 (PR#145)







Hi Michael, 

Scripted loops in XForms live outside of the XPath expression language in 
XForms. 

Also, in XForms the form author's perspective is that when they make a 
script change, then all calculations are performed.  The calculations are 
separate XPaths, but it is a little like running them in a loop whose 
order is determined by topological sorting.  The point is that in that 
case, which is conceptually similar to the one you pointed out, I have 
personally run a form that invoked now() twice-- in two separate XPaths-- 
and the one second boundary was crossed between the two executions. 
Similarly, UI refreshment is a time when there is the potential for a lot 
of change at once based on event handlers for the dispatched UI events. 
Again, these changes affect how succeeding XPaths will run even though the 
full set of XPaths are viewed as a 'batch' from the author's perspective. 

The point is that from XForms perspective, which combines DOM mutability 
with 'batch' XPath processing, the particular function in question 
presents no additional burden of care on the form author, nor 
unfortunately is there any other way to introduce this required feature 
that would not introduce the same burden of care on the form author. 

Best regards, 
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer




"Michael Kay" <mike@saxonica.com> 
Sent by: www-forms-editor-request@w3.org 
10/24/2007 02:35 AM 


To
"'John Boyer'" <xforms-issues@mn.aptest.com> 
cc
<w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org> 
Subject
RE: 7.8.8 (PR#145)









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 :)
> > 
> > 
> >