[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML design of ((a and b) or c)

• From: "Klotz, Leigh" <Leigh.Klotz@x...>
• To: "Michael Kay" <mike@s...>, "Rick Marshall" <rjm@z...>
• Date: Fri, 15 Dec 2006 17:12:06 -0800

Thank you; I'll take this off xml-dev and onto www-forms. Leigh. 

-----Original Message-----
From: Michael Kay [mailto:mike@s...] 
Sent: Friday, December 15, 2006 5:10 PM
To: Klotz, Leigh; 'Rick Marshall'
Cc: 'Ken North'; xml-dev@l...
Subject: RE:  XML design of ((a and b) or c)

 
> Personally, I would welcome any helpful suggestions you have 
> about upward compatibility, with XForms 1.1 and with XPath 2.0.

I think one useful idea would be to enable a function prefix (or absence
of
a prefix) to be bound essentially to a search path containing multiple
namespaces. The WG rejected this notion when I proposed it, but that's
because I presented it badly. In fact I think it's currently legal: we
don't
constrain how you build a library of functions and assign them to a
namespace, and one way of doing it is to assemble a new namespace from
multiple existing namespaces with a priority rule for resolving any
clashes:
a sort of "virtual function namespace". That mechanism would allow you
to
put the XForms functions in a separate namespace and then allow the user
to
bind a prefix to a URI that identifies a search path containing first
the
XForms functions and then the XPath 2.0 functions.

That leaves "if", which is a nasty problem. Technically you can probably
disambiguate the XForms function from the XPath 2.0 conditional
expression
by lookahead based on the presence of "then" after the ")", but that's
difficult to specify, and adds yet another nasty glitch to XPath
parsing.
Orbeon Forms has this problem because it already uses XPath 2.0, and I
think
it simply forces the user to prefix the "if" function.

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

• References:
  • RE: XML design of ((a and b) or c)
    • From: "Michael Kay" <mike@s...>