Re: Non-standard use of XPath location paths in XForms 1.0

Hi TV,

I was intrigued by your response. You claim that my post was "emotionally 
charged". Let me inform you that you are totally incorrect there. It was and 
is a wholly dispassionate point as far as I am concerned. The only emotion is 
a tinge of amusement at your aeration that the point should be raised.

Let's stick to the facts.

The XPath 1.0 Recommendation states:
"An absolute location path consists of / optionally followed by a relative 
location path.  A / by itself selects the root node of the document 
containing the context node. If it is followed by a relative location path, 
then the location path selects the set of nodes that would be selected by the 
relative location path relative to the root node of the document containing 
the context node.". That is stated in Chapter 2 of the XPath 1.0 
Recommendation.

It seems to me to be pretty unambiguous that a single forward slash at the 
beginning of an XPath 1.0 location path identifies the root node of the 
*document*.

Your response to my post indicates that it is a conscious choice on the part 
of the XForms WG to change the semantics of a single forward slash at the 
beginning of what purports to be an XPath 1.0 location path.

So, it seems to me that you accept that the current XForms 1.0 CR changes the 
semantics of the single forward slash at the beginning of a location path.

The question then becomes one of asking whether that is a sound idea - 
firstly, narrowly within the scope of XForms 1.0 and, secondly, more widely 
within other multinamespace XML documents which inevitably will become 
increasingly common over the next few years.

Should every new specification be allowed to label itself as using "XPath 
x.x" location paths while using the syntax to convey semantics other than 
were present in XPath 1.0 or whatever version is relevant?

My working hypothesis is that such a change is inappropriate, basically a bad 
idea and architecturally unsound. I am open to being persuaded otherwise

If you care to justify your charge of my post being an "emotionally charged 
red herring" I would be intrigued to know what it was based on.

Andrew Watt

At 4:35 GMT Standard Time, tvraman@us.ibm.com writes:


> Hi Tim --
> 
> Since Andrew's note is directly addressed to you, I'm also addressing
> my reply specifically to you.
> 
> His assertion that XForms 1.0 changes XPath sematnics is an
> emotionally charged red herring and probably reflects a lack of
> understanding.
> 
> XForms very carefully defines the evaluation context and  this is
> important for us to do since we dont want XForms controls and
> processing model actions touching random parts of the document.
> Specifically, XPath locators used to bind XForms controls to the
> underlying data instance only have access to the instance data
> contained within XForms data model
> --not to the entire document tree as Andrew appears to speculate.
> 
> --Raman 
> >>>>> "AndrewWatt2001" == AndrewWatt2001  <AndrewWatt2001@aol.com> writes:
> 
> 
>     AndrewWatt2001> I want to raise for discussion the impact of
>     AndrewWatt2001> non-standard use of XPath 1.0 location paths in
>     AndrewWatt2001> XForms 1.0. Since it seems to me that it could
>     AndrewWatt2001> raise issues relevant to the TAG I am copying it
>     AndrewWatt2001> to the most publicly facing TAG member.
> 
>     AndrewWatt2001> It seems to me that XForms 1.0 proposes to change
>     AndrewWatt2001> the semantics of XPath 1.0 location paths.
> 
>     AndrewWatt2001> What I mean by non-standard can be illustrated as
>     AndrewWatt2001> follows. Suppose we have a skeletal document
>     AndrewWatt2001> containing the bits of an XForms "form":
> 
>     AndrewWatt2001> <svg ...> <xforms:model> <xforms:instance ...>
>     AndrewWatt2001> <my:Element/> </xforms:instance> </xforms:model>
>     AndrewWatt2001> ... <!-- Other stuff here --> ... </svg>
> 
>     AndrewWatt2001> In XForms 1.0 the "XPath" location path to
>     AndrewWatt2001> reference the <my:Element> is likely to be
>     AndrewWatt2001> /my:Element.
> 
>     AndrewWatt2001> In standard XPath 1.0 that location path would
>     AndrewWatt2001> return an empty node-set. The "/" would refer to
>     AndrewWatt2001> the document entity of which the <svg> element is
>     AndrewWatt2001> the single child element node.
> 
>     AndrewWatt2001> To reference the <my:Element> element in standard
>     AndrewWatt2001> XPath 1.0 we could use something like //my:Element
>     AndrewWatt2001> or /xforms:model/xforms:instance/my:Element or
>     AndrewWatt2001> //xforms:model/xforms:instance/my:Element.
> 
>     AndrewWatt2001> If we wanted specifically to reference a
>     AndrewWatt2001> particular <xforms:model> element we could use
>     AndrewWatt2001> 
> //xforms:model[@id="whatever"]/xforms:instance/my:Element.
> 
>     AndrewWatt2001> The only advantage I can see of the current
>     AndrewWatt2001> non-standard approach is that it is slightly
>     AndrewWatt2001> shorter than the "correct" XPath 1.0 syntax.
> 
>     AndrewWatt2001> Is there any other advantage to the current
>     AndrewWatt2001> proposed approach?
> 
>     AndrewWatt2001> On the other side of the equation it does seem to
>     AndrewWatt2001> be a substantial departure from the semantics of a
>     AndrewWatt2001> standard XPath 1.0 location path.
> 
>     AndrewWatt2001> Additionally XForms 1.0 seems to be requiring an
>     AndrewWatt2001> "XPath" processor to behave in a way inconsistent
>     AndrewWatt2001> with XPath 1.0.
> 
>     AndrewWatt2001> Is the minor saving in keystrokes worth the
>     AndrewWatt2001> potential for confusion now and in the longer
>     AndrewWatt2001> term?
> 
>     AndrewWatt2001> Andrew Watt
> 
> -- 
> Best Regards,
> --raman
>