Title: Namespace for the document fragment representing a part
Sorry if the wording of my replies misled
you. My Issue is not really about the
part as type and property alias queries, but also XPath
1.0 vs. XPath 2.0 and the queries within bpel assignments and expressions. Even if we assume no namespaces in the document
fragment under the part as type case (which we should think hard about as validation
would be an issue), many of the messages would most definitely contain
namespaces and as such require qualification in XPath
1.0.
Chris
-----Original Message-----
From: Ugo Corda
[mailto:]
Sent: Thursday, August 07, 2003 1:46 PM
To:
;
Subject: RE: [wsbpel] Issue - 46 -
Namespace for the document fragment representing a part
The only exception would be the case
where the subelements are actually declared globally in the schema and then
referenced within the type (see the example in BP 1.0, sec. 5.6.21). But that
is not the case for the BPEL example on page 49.
Ugo
-----Original Message-----
From: Ugo Corda
Sent: Thursday, August 07, 2003 10:30 AM
To:
;
Subject: RE: [wsbpel] Issue - 46 -
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
