Title: Namespace for the document fragment representing a part
Could you mention
one specific example in the current spec that you think is incorrect from that
point of view?
Ugo
-----Original Message-----
From: Chris Keller
[mailto:]
Sent: Thursday, August
07, 2003 11:01 AM
To: Ugo Corda;
Subject: RE: [wsbpel] Issue - 46 -
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
