[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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="
</message>
<bpws:property
name="poNumber" type="xsd:positiveInteger"/>
<bpws:propertyAlias
propertyName="tns:poNumber" messageType="tns:poMessage" part=" 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----- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]