Title: Namespace for the document fragment representing a part
I disagree. Those
elements are local elements and, according to Schema 1 (section 3.3.2), they are
in no namespace (unless a elementFormDefault="qualified" has been specified for
the corresponding schema).
Ugo
-----Original Message-----
From: Chris Keller
[mailto:]
Sent: Thursday, August
07, 2003 10:24 AM
To: Ugo Corda;
Subject: RE: [wsbpel] Issue - 46 -
Namespace for the document fragment representing a part
I think that we
should assume that the elements under the part are fully qualified, meaning
that their QName is associated with the namespace in
the document fragment of the part.
-----Original
Message-----
From: Ugo Corda
[mailto:]
Sent: Thursday, August 07,
2003 12:56
PM
To: ;
Subject: RE: [wsbpel] Issue - 46 -
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
