Title: Namespace for the document fragment representing a part
Chris,
I don't think I
agree with your final conclusion.
If we decide, as
I proposed, to follow the BP 1.0 resolution, then a part defined
in terms of a type has no namespace (please notice: I am not talking about
default namespace here).
If the part has no
namespace, there is no prefix that can be used to identify the namespace of the
top element (as shown in the BP 1.0 example I pointed out below). This should
still be consistent with what XPath 1.0 says ("if the QName does not have a
prefix, then the namespace URI is null"). So a path starting with "/PO/..."
should be fine.
For what concerns
the complete path example you give, "/PO/tns:Header/tns:PONumber", I don't think
the tns prefix should be there. Assuming that elementFormDefault="unqualified"
for the corresponding schema (which is the default value), the local elements of
purchaseOrder should also be in no namespace.
Ugo
-----Original Message-----
From: Chris Keller
[mailto:]
Sent: Wednesday, August
06, 2003 7:50 PM
To: Ugo Corda;
Subject: RE: [wsbpel] Namespace for the
document fragment representing a part
Ugo,
I brought up the
issue. I believe this requires
clarification. First in XPath 1.0 there is no default namespace for evaluation
meaning that all names need to be qualified with a prefix. In XPath 2.0
there is the use of a default namespace, but this specification is referencing
1.0. Putting that aside for a
moment in both 1.0 and 2.0 no namespace is not equal to default
namespace. Let’s take an
example:
<message name="poMessage">
<part
name="PO" type="tns:purchaseOrder"/>
</message>
<bpws:property name="poNumber"
type="xsd:positiveInteger"/>
<bpws:propertyAlias propertyName="tns:poNumber"
messageType="tns:poMessage" part="PO"
query="/PO/Header/PONumber"/>
</bpws:propertyAlias>
If as you suggest we
assume that the Part PO is included in the query (which I agree with) and has
no namespace (namespace URI is null) association. This query in order to be correct in
XPath should be formulated
as:
/PO/tns:Header/tns:PONumber
Note the section Node
Tests from XPath 1.0 (http://www.w3.org/TR/xpath#node-tests
– section 2.3 Node Tests)
“A node test that is
a QName is true if and only if the type of the node
(see [5 Data Model]) is the principal node type and has an expanded-name equal
to the expanded-name specified by the QName. For
example, child::para selects the para element children of the context node; if the context
node has no para children, it will select an empty
set of nodes. attribute::href selects the href attribute of the context node; if the context node
has no href attribute, it will select an empty set
of nodes.
A QName in the node test is expanded into an expanded-name
using the namespace declarations from the expression context. This is the same
way expansion is done for element type names in start and end-tags except that
the default namespace declared with xmlns is not
used: if the QName does not have a prefix, then the
namespace URI is null (this is the same way attribute names are expanded). It
is an error if the QName has a prefix for which
there is no namespace declaration in the expression
context.”
-- Note the statement
“except that the default namespace declared with xmlns is not used: if the QName
does not have a prefix, then the namespace URI is
null”
Now in XPath 2.0 it is slightly different (http://www.w3.org/TR/xpath20/#node-tests
– section 3.2.1.2 Node Tests)
“A node test that
consists of a QName is called a name test. A name
test is true if and only if the kind of the node is the principal node kind
and the expanded-QName of the node is equal to the
expanded-QName specified by the name test. For
example, child::para selects the para element children of the context node; if the context
node has no para children, it selects an empty set
of nodes. attribute::abc:href selects the attribute of the
context node with the QName abc:href; if the context node has no such attribute, it
selects an empty set of nodes.
A QName in a name test is expanded into an expanded-QName using the in-scope namespaces in the expression
context. It is a static error if the QName has a
prefix that does not correspond to any in-scope namespace. An unprefixed QName, when used as a
name test on an axis whose principal node kind is element, has the namespaceURI of the default element namespace in the
expression context; otherwise, it has no namespaceURI.”
-- Note the
statement: “An unprefixed QName, when used as a name test on an axis whose principal
node kind is element, has the namespaceURI of the
default element namespace in the expression context; otherwise, it has no
namespaceURI.”
-- So in either case
we need to qualify the namespace for your message part declared as a type
example. And if we are following
the XPath 1.0 specification we should qualify all
elements that have a namespace since no default namespace is applied. In this case basically every query in
the bpel specification is incorrect and should
contain prefixes for all element names associated with namespaces in the XPath expressions.
I will continue to
submit the namespace in queries as a new issue unless we want to address it as
part of your original query clarification issue. Please let me know your
thoughts.
Chris
-----Original
Message-----
From: Ugo Corda
[mailto:]
Sent: Wednesday, August 06,
2003 9:50
PM
To:
Subject: [wsbpel] Namespace for the
document fragment representing a part
During today's discussion of item
39, somebody brought up the issue of which namespace is associated with the
document fragment representing a part. This is, of course, relevant to writing
path expressions in query attributes found in assignments and property aliases
declarations.
I imagine this should be an issue
only in the case where the part is defined in terms of a type. (If the part is
defined in terms of an element, I would assume the namespace should be the
same as the element's namespace).
In the case the part is defined in
terms of a type, I would follow what the WS-I Basic Profile 1.0 says in
section 5.6.20, Namespace for Part Accessors:
"R2735 A MESSAGE described with an
rpc-literal binding MUST place the part accessor elements for parameters and
return value in no namespace".
(See also the example in the
following section 5.6.21).
In other words, I would follow the
same direction and say that the top element of a document fragment
representing a part defined in terms of a type does not belong to any
namespace.
Ugo
