I fully agree with Steve - let's not invent another XPATH like syntax ..

Suman Kalia
IBM Toronto Lab
WebSphere Business Integration Application Connectivity Tools
Tel : 905-413-3923  T/L  969-3923
Fax : 905-413-4850
Internet ID : kalia@ca.ibm.com
----- Forwarded by Suman Kalia/Toronto/IBM on 01/19/2006 09:43 AM -----
Steve Hanson <smh@uk.ibm.com>
Sent by: owner-dfdl-wg@ggf.org

01/19/2006 04:43 AM

To
"Westhead, Martin (Martin)" <westhead@avaya.com>
cc
dfdl-wg@ggf.org, owner-dfdl-wg@ggf.org
Subject
Re: [dfdl-wg] Ambiguous XPaths to hidden elements





As a DFDL parser implementor I do not want modifications to the XPath
syntax. I want to be able to reuse existing XPath implementations. It's
also something else for the user to have to learn. So 2a/b/c are not
attractive.

Regards, Steve

Steve Hanson
WebSphere Message Brokers,
IBM Hursley, England
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848


                                                                         
            "Westhead, Martin                                            
            (Martin)"                                                    
            <westhead@avaya.c                                          To
            om>                       <dfdl-wg@ggf.org>                  
            Sent by:                                                   cc
            owner-dfdl-wg@ggf                                            
            .org                                                  Subject
                                      [dfdl-wg] Ambiguous XPaths to      
                                      hidden elements                    
            18/01/2006 20:24                                              
                                                                         
                                                                         
                                                                         
                                                                         
                                                                         




Hi folks,

This is to try to pick up on the issue identified by Suman in today’s call.

The Issue
Consider the following example:

<xs:element name="root">
<xs:complexType>
                               <xs:sequence>
                                               <xs:annotation><xs:appinfo
source=”http://dataformat.org” />
                                            <hidden>
<xs:element name="repeats" type="xs:integer"/>
                                                               </hidden>

</xs:appinfo></xs:annotation >
                               <xs:element              name="testElement"
type="xs:integer " minOccurs=”0” maxOccurs=”unbounded”
                                dfdl:repeatCount=”../repeats”>
               </xs:complexType>
</xs:element>

The problem is that the path “../repeats” can be broken by modifications to
the logical model due to name clashes on “repeats” and there are cases that
can be constructed where this would not be obvious to a user.

Possible Solutions
Possible fixes to this include:
  1.  Disallow  XPath  references to hidden elements the user is forced to
     place the material into the global context to refer to it.
  2.  Provide  a  special  XPath operator to indicate we are referencing a
     hidden element, possibilities include:
        a. “../hidden(repeats)”
        b.  “hidden(../repeats)”
        c.  “../dfdl:hidden/repeats”
  3.  Only allow hidden elements to be present in top level global complex
     types. These can then be included where needed. (This is the solution
     that  Suman  was  pushing  but  I  don’t  fully  understand  it  – in
     particular I don’t see how it resolves the ambiguity issue.)


I believe my preference here is 2a or 2b followed by 1.

Comments/suggestions/opinions?

Thanks,

Martin