Non-standard use of XPath location paths in XForms 1.0

I want to raise for discussion the impact of non-standard use of XPath 1.0 
location paths in XForms 1.0. Since it seems to me that it could raise issues 
relevant to the TAG I am copying it to the most publicly facing TAG member.

It seems to me that XForms 1.0 proposes to change the semantics of XPath 1.0 
location paths.

What I mean by non-standard can be illustrated as follows. Suppose we have a 
skeletal document containing the bits of an XForms "form":

<svg ...>
<xforms:model>
 <xforms:instance ...>
   <my:Element/>
 </xforms:instance>
</xforms:model>
...
<!-- Other stuff here -->
...
</svg>

In XForms 1.0 the "XPath" location path to reference the <my:Element> is 
likely to be /my:Element.

In standard XPath 1.0 that location path would return an empty node-set. The 
"/" would refer to the document entity of which the <svg> element is the 
single child element node.

To reference the <my:Element> element in standard XPath 1.0 we could use 
something like //my:Element or /xforms:model/xforms:instance/my:Element or 
//xforms:model/xforms:instance/my:Element.

If we wanted specifically to reference a particular <xforms:model> element we 
could use //xforms:model[@id="whatever"]/xforms:instance/my:Element.

The only advantage I can see of the current non-standard approach is that it 
is slightly shorter than the "correct" XPath 1.0 syntax.

Is there any other advantage to the current proposed approach?

On the other side of the equation it does seem to be a substantial departure 
from the semantics of a standard XPath 1.0 location path. 

Additionally XForms 1.0 seems to be requiring an "XPath" processor to behave 
in a way inconsistent with XPath 1.0.

Is the minor saving in keystrokes worth the potential for confusion now and in
 the longer term?

Andrew Watt

Received on Wednesday, 13 November 2002 11:19:45 UTC