I would want to change XPath only as a last resort. (Any of the options is OK by me, assuming we have to mess with the Xpath at all.) Can we deal with this some other way? Can we document the problematic cases, and suggest best practices that will minimize the problem? On Thursday 19 January 2006 08:45, Suman Kalia wrote:
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
-- --- Robert E. McGrath, Ph.D. National Center for Supercomputing Applications University of Illinois, Urbana-Champaign 1205 West Clark Urbana, Illinois 61801 (217)-333-6549 mcgrath@ncsa.uiuc.edu