Fw: [dfdl-wg] Ambiguous XPaths to hidden elements
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
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
One idea that hasn't been advanced yet is ruling out the problematic case. Let me illustrate. Here's the example, modified to have a model group reference which can introduce the name conflict: <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:group ref="groupFromOtherSchemaFile"/> <!-- what if this has an element decl named "repeats"? --> </xs:complexType> </xs:element> So, what hasn't been suggested yet is this: What if we just say DFDL doesn't allow this? It's an error which must be detected. This DFDL schema is broken because the path "../repeats" cannot be analyzed along with the DFDL schema to return only a single node. I beleive name conflicts like this are what namespace management is for. XSD has truly great namespace managment. You can solve the problem that way. Furthermore, when you define a reusable named group like the definer of the "groupFromOtherSchemaFile" above, and you put it in no target namespace, that's the situation where this conflict can arise. Expecting that your names are never going to conflict with anything in that case is just naive. It's equivalent to having global variables in a C program module and expecting you can never link it to something else that uses the same names. Those name conflicts can occur, and someone has to change the conflicting name. In XSD we can do that by including the group in a schema which puts it into a target namespace so that after that the namespaces can be used to disambiguate. The approach above is consistent with the path "../repeats" still being officialy an "XPath", it just adds the semantic restriction that it must be an XPath that identifies a single node unambiguously, independent of what data is being processed. This is one of these "data independent" notions (what I had previously been calling "static"), as we discussed yesterday. ...mikeb "Robert E. McGrath" <mcgrath@ncsa.uiuc.edu> Sent by: owner-dfdl-wg@ggf.org 01/19/2006 10:00 AM To dfdl-wg@ggf.org cc Subject Re: Fw: [dfdl-wg] Ambiguous XPaths to hidden elements 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
Another thought comes to mind on this. There's a spec called XPointer. This is based on XPath, but extends its semantics in various ways. Quick skim of this suggests to me that we would not be entirely out of line to make the extensions we need. E.g., consider this section excerpted from the XPointer 1.0 document: 5 XPointer Extensions to XPath XPointer extends XPath by adding the following: A generalization of the XPath concepts of nodes, node types, and node-sets to the XPointer concepts of locations, location types, and location-sets, which subsume nodes, points, and ranges. Two new location types, point and range, corresponding to DOM positions and ranges, that can appear in location-set results; also tests (akin to node tests) for these location types. Rules for establishing the XPath evaluation context. The functions string-range and range-to, which return the range location type for selections that are not single XML nodes. The functions here and origin, to provide for addressing relative to the location of an XPointer expression itself, and to the point of origin for hypertext traversal when XPointers are used in that (very common) application domain. The functions start-point and end-point, to address the beginning and ending locations which bound another location such as a node or range. Like [XSLT], XPointer allows the root node to have multiple child elements, to allow XPointers to address into arbitrary external parsed entities as well as well-formed documents. I find the last bullet particularly interesting as the XSD/XML insistance on a single top document node for all data is generally annoying and simply artificial for much non-XML data. Mike Beckerle STSM, Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA 01581 voice and FAX 508-599-7148 home/mobile office 508-915-4767 "Robert E. McGrath" <mcgrath@ncsa.uiuc.edu> Sent by: owner-dfdl-wg@ggf.org 01/19/2006 10:00 AM To dfdl-wg@ggf.org cc Subject Re: Fw: [dfdl-wg] Ambiguous XPaths to hidden elements 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
Looking at W3C the excerpt below is from a working draft from 2001. It looks to have evolved into this working draft from 2002: XPointer xpointer() Scheme. Regards, Steve Steve Hanson WebSphere Message Brokers, IBM Hursley, England Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 Mike Beckerle <beckerle@us.ibm. com> To Sent by: "Robert E. McGrath" owner-dfdl-wg@ggf <mcgrath@ncsa.uiuc.edu> .org cc dfdl-wg@ggf.org, owner-dfdl-wg@ggf.org 19/01/2006 16:08 Subject XPointer? (was: Re: Fw: [dfdl-wg] Ambiguous XPaths to hidden elements) Another thought comes to mind on this. There's a spec called XPointer. This is based on XPath, but extends its semantics in various ways. Quick skim of this suggests to me that we would not be entirely out of line to make the extensions we need. E.g., consider this section excerpted from the XPointer 1.0 document: 5 XPointer Extensions to XPath XPointer extends XPath by adding the following: A generalization of the XPath concepts of nodes, node types, and node-sets to the XPointer concepts of locations, location types, and location-sets, which subsume nodes, points, and ranges. Two new location types, point and range, corresponding to DOM positions and ranges, that can appear in location-set results; also tests (akin to node tests) for these location types. Rules for establishing the XPath evaluation context. The functions string-range and range-to, which return the range location type for selections that are not single XML nodes. The functions here and origin, to provide for addressing relative to the location of an XPointer expression itself, and to the point of origin for hypertext traversal when XPointers are used in that (very common) application domain. The functions start-point and end-point, to address the beginning and ending locations which bound another location such as a node or range. Like [XSLT], XPointer allows the root node to have multiple child elements, to allow XPointers to address into arbitrary external parsed entities as well as well-formed documents. I find the last bullet particularly interesting as the XSD/XML insistance on a single top document node for all data is generally annoying and simply artificial for much non-XML data. Mike Beckerle STSM, Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA 01581 voice and FAX 508-599-7148 home/mobile office 508-915-4767 "Robert E. McGrath" <mcgrath@ncsa.uiuc.edu> Sent by: owner-dfdl-wg@ggf.org To dfdl-wg@ggf.org 01/19/2006 10:00 AM cc Subject Re: Fw: [dfdl-wg] Ambiguous XPaths to hidden elements 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
participants (4)
-
Mike Beckerle -
Robert E. McGrath -
Steve Hanson -
Suman Kalia