[DFDL-WG] Action 274 - on qnames in path expressions in DFDL

[Mike Beckerle]

Tim,

How do you do this? => "You define a non-empty prefix that points to an
empty namespace, and use that prefix in the QName."


specifically, what XML text corresponds to "an empty namespace".

xmlns:foo="" isn't allowed (in eclipse anyway)


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 Thu, Oct 16, 2014 at 12:58 AM, Tim Kimber <KIMBERT at uk.ibm.com> wrote:

> My off-the-cuff reactions:
> - every conforming XPath processor allows a 'namespace context' to be
> defined. The context defines a prefix->namespace URI mapping for zero or
> more prefixes.
> - namespace prefixes ( including the empty prefix ) are then interpreted
> in exactly the same way as they would be in an XML document. This makes
> sense, because XPaths were explicitly designed to be included within XML
> documents. It would look rather strange if the prefixes within an XPath
> were to be interpreted differently by a) an XML processor and b) an XPath
> processor.
> I think that answers most of the queries, although it raises a question
> over whether the Eclipse implementation is conforming.
>
> re: the question about empty prefixes, there is a (non-obvious) way to
> refer to a noTargetNamespace global element from within a document that has
> a default namespace. You define a non-empty prefix that points to an empty
> namespace, and use that prefix in the QName.
>
> regards,
>
> Tim Kimber,
> Technical Lead for IBM Integration Bus Healthcare Pack
> Hursley, UK
> Internet:  kimbert at uk.ibm.com
> Tel. 01962-816742
> Internal tel. 37246742
>
>
>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
> Date:        16/10/2014 01:41
> Subject:        [DFDL-WG] Action 274 - on qnames in path expressions in
> DFDL
> Sent by:        dfdl-wg-bounces at ogf.org
> ------------------------------
>
>
>
>
> I did some experiments with the XML validation built into eclipse, and the
> key constraint, which has paths (in the selector and field attributes) that
> refer to other parts of the XML infoset/document and so involve the names
> of elements.
>
> I also have been reading the XPath 2.0 specs including the formal
> semantics. To my interpretation XPath 2.0 is pretty explicit:
>
> An element or type QName consisting only of a local part NCName expands to
> the default element/type namespace and the local part.
>
> They don't qualify this in any way that I can find for the names used in
> path steps. The formal semantics is pretty hard to understand, but this
> detail seems to be swept under the rug. There would need to be specific
> treatment of this in the naming environment, but I cannot find this. There
> is discussion of name resolution in some of their judgements, but nothing I
> can see that creates an exception for names in path steps. (Called name
> tests)
>
> What I was looking for was language that specifies something about a
> non-prefixed name in a path step and that it is NOT augmented by the
> default namespace. I could find no such exception.
>
> But if I am right and this detail isn't there, i.e., If there is no such
> exception, then the implementation of XPath in eclipse (which is xerces I
> believe) is incorrect in the way it resolves names that appear in path
> steps.
>
> Here's how it works according to eclipse:
>
> In xpath expressions in the selectors and fields of unique and key
> constraints, xmlns (the default namespace) is not considered as implicitly
> augmenting unqualified names that appear in path steps.
>
> An identifier in a path step that has no prefix (e.g., 'foo' in the path
> './p1:bar/foo/p2:baz') is always interpreted as identifying either
>
> 1) a child element defined by a local element declaration with form
> "unqualified".
> or
> 2) this corner case: a child element defined by an element reference to a
> global element declaration but only when that global element declaration
> has no effective target namespace. (Use of 'effective' here rules out an
> element decl inside a schema document that itself has no target namespace
> but is included into a schema that has one. Such an element declaration
> effectively has a target namespace, so this corner case doesn't apply.)
>
> Case (2) here is a rather obscure corner case, but there nevertheless.
>
> In no case (that I could construct) does the name in a path step get
> augmented by a schema's default namespace (defined by
> xmlns="...whatever...").
>
> The above is true for names without prefix appearing in path steps of
> expressions.
>
> The QNames that are used in an XML schema to reference a global
> declaration or definition (in the ref of an element ref, type attribute in
> a type reference, base in a simple type derivation, etc.) are different.
> Those names DO pickup a default namespace if one is defined and they have
> no explicit prefix themselves. This creates a corner case for these
> references (to global decls/defs) which is if a definition/declaration
> appears in no effective target namespace, then there is no way to reference
> it at all from a schema that has a default namespace definition surrounding
> the point of reference. There is no syntactic way to turn-off use of a
> default namespace. (The semantics of xpath allows for a "none" default
> namespace definition, but there is no xml syntax for expressing explicitly
> this "none". It is simply what you have if there is no prefix and no
> default namespace). You can change which namespace the default is, but
> there's no way to say explicitly "I meant this QName reference to be to
> something not in any namespace.
>
> Unless/until we can find language in some XML Schema spec indicating how
> path step names (name tests) are specifically resolved, then the above is
> just "how one system does it." But we may end up having to follow precedent
> here from implementations.
>
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
> *www.tresys.com* <http://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>
> --
>  dfdl-wg mailing list
>  dfdl-wg at ogf.org
>  https://www.ogf.org/mailman/listinfo/dfdl-wg
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
> --
>   dfdl-wg mailing list
>   dfdl-wg at ogf.org
>   https://www.ogf.org/mailman/listinfo/dfdl-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20141016/4f37bc11/attachment.html>