Re: Fw: Section 7 (PR#139)

Hi John,

yes, of course you are right about count(). Thanks for spotting this.
Bad example, but I hope my intent was clear at least:

When we require strict type matching, we ignore auto conversion, e.g.
string-length(/some/node) would yield an xforms-compute-exception
because string-length() expects a parameter of type string. This would
obviously be too restrictive.

Regards,
Uli.

John Boyer wrote:
> 
> Hi Uli,
> 
> I fixed this by removing the part about function parameters.  This I did
> because count("x") actually isn't an error, I believe.  I believe it
> should just produce NaN.  But doesn't count(number("7")) also produce
> NaN?  
> 
> 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
> 
> 
> 
> 
> *Ulrich Nicolas Lissé <unl@dreamlab.net>*
> Sent by: public-forms-request@w3.org
> 
> 11/02/2007 03:01 PM
> 
> 	
> To
> 	ebruchez@orbeon.com
> cc
> 	"Forms WG (new)" <public-forms@w3.org>
> Subject
> 	Re: Fw: Section 7 (PR#139)
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> Erik, all,
> 
> this all sounds quite perfect to me, except for function parameters: In
> XPath 1.0 function arguments are converted automatically to the required
> type ([1]). So count("x") is surely an error, but count("7") is not
> because it is equivalent to count(number("7")).
> 
> I think it is too restrictive to require the types of function
> parameters to match the types defined by the function because it ignores
> automatic type conversion (which hampers static analysis as well).
> 
> Regards,
> Uli.
> 
> [1] http://www.w3.org/TR/xpath#section-Function-Calls
> 
> Erik Bruchez wrote:
>>
>> John & all,
>>
>> he is the current text in section "7 XPath Expressions in XForms":
>>
>>   "XPath expressions that are not syntactically valid, including
>>    attempted calls to undefined functions, result in an exception
>>    (4.5.4 The xforms-compute-exception Event), except for binding
>>    expressions, which produce a different exception (4.5.1 The
>>    xforms-binding-exception Event)."
>>
>> What about something like this for the new text:
>>
>>   "At the time of evaluation, an XPath expression must be
>>    syntactically correct. In addition, the namespaces the expression
>>    references must be in scope, the functions it references must be
>>    defined and the types of function parameters must match the types
>>    defined by the function. If any of these conditions is not
>>    satisfied, an exception (4.5.4 The xforms-compute-exception Event),
>>    is raised except for binding expressions, which produce a different
>>    exception (4.5.1 The xforms-binding-exception Event)."
>>
>> I enumerate the aspects of the XPath 1.0 context that matter to us. I
>> left out variable declarations as those are not supported in XForms
>> 1.0 and 1.1 (unfortunately), and we explicitly say so further down in
>> the spec. The above is more complete than the original text, and at
>> the same time does not attempt to define static vs. dynamic context in
>> XPath 1.0.
>>
>> However, it does leave out what happens if an error occurs at runtime
>> within an extension function (see section "7.12 Extension
>> Functions"). Those functions I think are the only ones that could
>> actually "fail" *while* the function is evaluated, as all the XPath
>> 1.0 and XForms 1.1 functions otherwise always return a result,
>> whatever the parameters passed to them (assuming the params match the
>> types).
>>
>> So I think we should add something like this to the above:
>>
>>   "If an error occurs while evaluating an extension function, then an
>>    exception (4.5.4 The xforms-compute-exception Event), is raised
>>    except for binding expressions, which produce a different exception
>>    (4.5.1 The xforms-binding-exception Event)."
>>
>> Ok, the above should cover issue 139. Comments of course are welcome.
>>
>> A side note: remember John that I mentioned, wrt static errors, that
>> an implementation could look at all XPath expression in the document
>> at load time (e.g. during a "static analysis" phase of processing)? I
>> find in the spec some text in 7.12 to that effect:
>>
>>   "Explicitly declaring extension functions enables XForms Processors
>>    to detect the use of unimplemented extension functions at document
>>    load-time, rather than throwing a fatal error during user
>>    interaction. Failure by authors to declare extension functions will
>>    result in an XForms Processor potentially halting processing during
>>    user interaction with a fatal error."
>>
>> (This is one of those rare cases where the spec explicitly describes
>> the rationale for a decision. I for one would like more of those.)
>>
>> Anyway, that paragraph seems to be an attempt in XForms at specifying
>> that processors are allowed to perform a static analysis of XPath
>> expressions at load time. From here to say that processors *should*
>> analyze all XPath expressions in the document statically in order to
>> provide authors and users with early error notification, there is only
>> a small step, which I think would be positive for XForms.
>>
>> -Erik
>>
>> John Boyer wrote:
>>>
>>> Hi Erik,
>>>
>>> Here is a response from Michael Kay that is quite informative
>>> regarding the kinds of things you would need to keep in mind while
>>> formulating a fix for issue #139.
>>>
>>> He's clearly right about missing namespace prefixes of course (I
>>> basically forgot to list that, so do double-check the actual XPath 1.0
>>> context definition).
>>>
>>> Also, if I read correctly, he is pointing out that type mismatches can
>>> occur, and could be viewed as static or dynamic.  The two examples of
>>> type mismatches that he gave are parameters (e.g. count receiving a
>>> string) and invalid caste operations (e.g. union of non-nodeset).
>>>
>>> If the wording is done well, I think we may not have to make the
>>> distinction, i.e. we do not have to care whether a particular XPath
>>> 1.0 implementation treats these as static or dynamic.
>>> I think the more careful wording should take the form of saying that
>>> at all times the exception occurs *when the XPath evaluation is
>>> performed*.
>>>
>>> Cheers,
>>> 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
>>>
>>>
>>> ----- Forwarded by John Boyer/CanWest/IBM on 10/24/2007 12:33 PM -----
>>> *"Michael Kay" <mike@saxonica.com>*
>>> Sent by: www-forms-editor-request@w3.org
>>>
>>> 10/24/2007 12:29 PM
>>>
>>>    
>>> To
>>>     "'John Boyer'" <xforms-issues@mn.aptest.com>
>>> cc
>>>     <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org>
>>> Subject
>>>     RE: Section 7 (PR#139)
>>>
>>>
>>>    
>>>
>>>
>>>
>>>
>>>
>>>
>>> That's fine.
>>>
>>> Undefined namespace prefixes are another possibility, in case you are
>>> enumerating them.
>>>
>>> In fact XPath 1.0 doesn't distinguish very carefully between static and
>>> dynamic errors, so count("xyz") is an error that can be reported either
>>> statically or dynamically, similarly ($x|3).
>>>
>>> Michael Kay
>>>
>>>  > -----Original Message-----
>>>  > From: John Boyer [mailto:xforms-issues@mn.aptest.com]
>>>  > Sent: 24 October 2007 20:00
>>>  > To: mike@saxonica.com
>>>  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
>>>  > Subject: Re: Section 7 (PR#139)
>>>  >
>>>  > Hi Michael,
>>>  >
>>>  > The working group agrees that this is a problem and will fix
>>>  > it in the specification.  For XPath 1.0, the static errors
>>>  > appear to be limited to expression well-formedness, undefined
>>>  > variable references and undefined function references as
>>>  > issues with the [context node, position, size] are handled
>>>  > separately, i.e. their non-availability implies not executing
>>>  > the xpath and behaving as if empty nodeset were returned.
>>>  >
>>>  > Please let us know if you have any further concerns about this issue.
>>>  >
>>>  > Thank you,
>>>  > John Boyer
>>>  >
>>>  > >
>>>  > >
>>>  > >
>>>  > >     D. "XPath expressions that are not syntactically valid": should
>>>  > >     cover all static errors, not just syntax errors. (Other static
>>>  > >     errors include, for example, references to functions or
>>>  > variables
>>>  > >     not present in the context, and type errors detected
>>>  > statically).
>>>  > >
>>>  > >
>>>  > >
>>>  > >
>>>
>>>
>>
>>
> 
> 
> -- 
> Ulrich Nicolas Lissé
> 
> 


-- 
Ulrich Nicolas Lissé

Received on Thursday, 8 November 2007 20:12:17 UTC