Non-standard use of XPath location paths in XForms 1.0

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
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
Architect:    Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608   T-Line 457-2608
Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
Email:        tvraman@us.ibm.com
WWW:      http://www.cs.cornell.edu/home/raman
AIM:      TVRaman
PGP:          http://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Wednesday, 13 November 2002 11:53:46 UTC