Re: Fw: Section 7 (PR#139)

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


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Wednesday, 31 October 2007 20:12:32 UTC