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

[Tim Kimber]

I think Eclipse must be doing something non-standard then:
http://stackoverflow.com/questions/1587891/is-xmlns-a-valid-xml-namespace

Which version of Eclipse / Eclipse plugin are you using?

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:     Tim Kimber/UK/IBM at IBMGB
Cc:     "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
Date:   16/10/2014 14:52
Subject:        Re: [DFDL-WG] Action 274 - on qnames in path expressions 
in DFDL




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


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 
Please note: Contributions to the DFDL Workgroup's email discussions are 
subject to the OGF Intellectual Property Policy 
--
 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


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20141017/4414a6ec/attachment.html>