<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