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@uk.ibm.com
Tel. 01962-816742
Internal tel. 37246742
From:
Mike Beckerle <mbeckerle.dfdl@gmail.com>
To:
"dfdl-wg@ogf.org"
<dfdl-wg@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@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
Please note: Contributions to the DFDL Workgroup's email
discussions are subject to the OGF
Intellectual Property Policy
--
dfdl-wg mailing list
dfdl-wg@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