Forwarded message 1
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é