Ambiguous XPaths to hidden elements
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
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
participants (2)
-
Steve Hanson -
Westhead, Martin (Martin)