[DFDL-WG] referencing local element declarations from path expressions between two schema documents

[Mike Beckerle]

Roger,

I am struggling to defend the semantics you suggest below, because I cannot
find anything in the XSD spec that specifically says how path steps are
interpreted.

In the absence of that, other members of the DFDL workgroup argue that path
steps are just references to elements, and the default xmlns definition
should work exactly as it works for any QName. So if the default namespace
is defined, then a name with no prefix is by default interpreted relative
to that definition.  Hence, you have to do this:

<xs:schema xmlns="BB"... >
   ....
   <xs:key name="myKey">
     <xs:selector path="a:foo/bar" xmlns=""/>
     ...

That is to say, if you wish to refer to locally declared elements with form
unqualified, you cannot have a default namespace in effect, and the above
provides the way you work around this, which is you explicitly reset the
default namespace to "" meaning no-namespace.

So is there anything you know of in the XSD spec that clarifies this, or is
this only clarified based on precedent of how it works in Xerces XSD
validator, but also Schematron, XSLT, etc.

I have struggled to interpret the formal semantics document about XSD. My
read of it did not find clarification of this point, but I confess to not
understanding it sufficiently to be sure.

Thanks in advance

...mike beckerle


Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
www.tresys.com
Please note: Contributions to the DFDL Workgroup's email discussions are
subject to the OGF Intellectual Property Policy
<http://www.ogf.org/About/abt_policies.php>


On Wed, Sep 17, 2014 at 8:30 AM, Costello, Roger L. <costello at mitre.org>
wrote:

>  Hi Mike,
>
>
>
> 1. In XSD only the global stuff can be referenced. So this is not allowed:
>
>
>
>                 <xs:element ref="bb:b1/c1">
>
>
>
> 2. When using xs:key the XPath expression in @path must have a namespace
> prefix even if the targetNamespace is the
>
> default namespace. Eg. *bk:Book. *If the schema had instead set
> elementFormDefault="unqualified" then the XPath expressions would not be
> namespace-qualified.
>
>
>
> 3. If you embed Schematron in an XSD file, during processing the
> Schematron processor will extract out the Schematron and generate an XSLT
> program. At that point you are in the world of XSLT and ordinary XPath
> rules apply. So if BB.xsd has declared a global element {BB}b1 which
> contains {}c1 then the XPath expression to reference c1 in an instance
> document is this: bb:b1/c1 (where bb has been bound to BB in the
> Schematron/XSLT code). It’s irrelevant to Schematron/XSLT whether the XML
> Schemas have/don’t have a default namespace declaration.
>
>
>
> /Roger
>
>
>
> *From:* Mike Beckerle [mailto:mbeckerle.dfdl at gmail.com]
> *Sent:* Wednesday, September 17, 2014 4:37 AM
> *To:* dfdl-wg at ogf.org; Costello, Roger L.
> *Subject:* referencing local element declarations from path expressions
> between two schema documents
>
>
>
>
>
> I am looking for clarification about how path steps are to be interpreted
> with respect to the issue of qualified/unqualified element names, and
> default or no-default namespaces.
>
> If there is a precedent we can follow set by other tools which embed paths
> into XSD (e.g., schematron?) or even just the selector/paths things in XSD
> key/uniqueness constraints then I'd like to understand it.
>
> These are some of the conundrums:
>
>
> Two Schema Files: A, and B
>
> Schema file A has target namespace AA, and binds the AA namespace to
> prefix aa, and the BB namespace to prefix bb
>
> Schema file B has target namespace BB, and the same prefix bindings.
>
> Schema B has an element named b1 which has two local element declarations
> inside it named c1 and c2.
>
> Schema A has an element named a1 which contains an element reference to
> bb:b1.
>
> a1 has a DFDL annotation (e.g., dfdl:assert) which has a path expression
> in it.  this path contains bb:b1/c1
>
> When is the path correct?
>
> 1a) when schema B has elementFormDefault='unqualified' (that's the
> default), and schema A does NOT have a default namespace. Why? the default
> namespace - if it existed for schema A - would implicitly qualify the c1
> step of the path, but since c1 is a local element in schema B with element
> form unqualified, it does not require (and cannot have) a namespace
> specified in path steps for c1.
>
> 1b) when schema B has elementFormDefault='qualified', and schema A has
> xmlns='BB'. Why? Because in this case the path bb:b1/c1 is equivalent to
> bb:b1/bb:c1, and since c1 will have a namespace-qualified name in schema B,
> that path will properly describe the path to the c1 element.
>
> 1c) Variation: when schema B has no target namespace (which I believe
> makes elementFormDefault irrelevant), and schema A has no default
> namespace. Because then c1 can't be qualfied as it lives in no namespace,
> and schema A has no implied qualifiers.
>
>
>
> When is the path incorrect?
>
> 2a) when schema A has xmlns="BB". Why? Because the default namespace means
> the bb:b1/c1 is equivalent to {BB}b1/{BB}c1, but there is no {BB}/c1 since
> c1 is just a local element declaration, and B has elementFormDefault
> unqualified.
>
> 2b) when schema B has elementFormDefault='qualified', and schema A has no
> default namespace. In that case the step c1 needs a namespace qualifier
> either by default, or explicitly via a prefix, but it doesn't have one.
>
> So I am interested in opinions on whether the above analysis is correct or
> not, and especially in precedent for how this stuff works in other tools.
>
> I have made a big assumption above which is that if xmlns="BB", then any
> path step inside something carrying that default binding is interpreted as
> qualified by that namespace. I picked this because it seemed reasonable,
> and it seems one can always modify one's schema to properly address
> something in another schema without having to change that other schema.
> I.e., it seems to have good composition properties.
>
> Thanks for any thoughts.
>
>
>
>
>
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
> www.tresys.com
>
> Please note: Contributions to the DFDL Workgroup's email discussions are
> subject to the OGF Intellectual Property Policy
> <http://www.ogf.org/About/abt_policies.php>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20141117/afd3d33a/attachment.html>