I am also uncomfortable with option #3,
but I’m not sure if option #1 is sufficient. The problem is that in the
processing of the message, if the namespace prefixes are modified, or even
removed (by declaring the appropriate namespace as the default namespace) in
the enclosing XML, then the receiver has no way to resolve what the XPath really
means.
For instance the example (some stuff left
out for clarity):
<s12:Envelope
…
xmlns:ex="http://example.com/exampleNS">
<s12:Header>...</s12:Header>
<s12:Body>
<wsrp:QueryResourceProperties>
<wsrp:QueryExpression
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116" >
boolean(/*/ex:NumberOfBlocks > 20 and /*/ex:BlockSize=1024)
</wsrp:QueryExpression>
</wsrp:QueryResourceProperties>
</s12:Body>
</s12:Envelope>
Could be transformed into:
<s12:Envelope
…
xmlns ="http://example.com/exampleNS">
<s12:Header>...</s12:Header>
<s12:Body>
<wsrp:QueryResourceProperties>
<wsrp:QueryExpression
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116" >
boolean(/*/ex:NumberOfBlocks > 20 and /*/ex:BlockSize=1024)
</wsrp:QueryExpression>
</wsrp:QueryResourceProperties>
</s12:Body>
</s12:Envelope>
Now the default namespace is http://example.com/exampleNS and the ex
prefix is removed. Both messages will C14N the same, but the receiver has no
way of know what ex:NumberOfBlocks means.
Option #3 solves this problem, but
requires duplication of the namespace information. It may also require the
service implementer to have to remap the XPath namespaces before using.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
Try the industry's only
100% .NET-enabled identity management software. Download your free copy of
Universal IdP Standard Edition today. Go to www.opennetwork.com/eval.
-----Original Message-----
From: Steve Graham
[mailto:sggraham@us.ibm.com]
Sent: Tuesday, August
10, 2004 9:20 AM
To: Vambenepe, William N
Cc: wsrf@lists.oasis-open.org
Subject: Re: [wsrf] Discussion on
issue 24
William:
Good
email, good walk through of the options.
I
would be very uncomfortable with option #3, it seems to be gratuitious
reinvention.
I
would be very much in favour of option #1, this seems to be the most natural.
Adding additional non-normative text to describe certain precautions to be
considered.
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy
of Technology
<Soli Deo Gloria/>
++++++++
"Vambenepe,
William N" <vbp@hp.com> wrote on 08/09/2004 10:19:26 PM:
>
> Hi all,
>
> On the call today I took an AI to start a
thread to further discuss
> issue 24.
>
> The problem is to decide unambiguously what
namespace declarations to
> take into account when evaluating an Xpath
expression contained in a
> QueryResourceProperty element. On the call,
we pretty much agreed that
> we want some kind of namespace mapping to
take place for prefixes in the
> Xpath expression (the alternative, string
comparison of prefixes between
> the Xpath expression and the target XML
document, is not desirable). The
> question then is what namespace declarations
to take into account.
>
> Option #1: whatever is in scope at the
QueryResourceProperty element:
> the namespace declaration can be on any
parent of the
> QueryResourceProperty element, as long as
they haven't been overwritten
> they are in scope.
>
> Option #2: only the namespace declarations
that are on the
> QueryResourceProperty element. Namespace
declarations on parent elements
> are irrelevant for the Xpath processing.
>
> The benefit of #2 is that you isolate
yourself from namespace
> declarations added later on by other software
modules (for example added
> on the SOAP envelop). But the problem of #2
is that these same software
> modules might decide to move namespace
declarations around (for exmaple
> move them all to the root element).
>
> In any case, there always is a risk that some
module will mess up with
> namespace declarations (and rename all the
prefixes for example) and
> this module will likely not touch the Xpath
expression itself. The only
> way for us to be 100% safe is to not use XML
namespace mechanisms for
> namespace declarations that apply to the
Xpath expression but specify
> them in our own format. This would be option
#3:
>
> Option #3: Create a NamespaceDeclaration
element and allow people to
> stuff an arbitrary number of these in the
QueryResourceProperty element.
> The NamespaceDeclaration element would look
something like that:
> <NamespaceDeclaration>
> <Prefix>foo</Prefix>
>
<Namespace>http://foo.com/foo</Namespace>
> </NamespaceDeclaration>
> Implementers would use these mappings to know
what to map prefixes in
> the Xpath statement to.
>
> At this point, I think we should either do
the "right thing" (at the
> cost of more coding work for the WSRF
implementers) which is #3 or the
> intuitive thing which is #1. I say forget #2
(I only listed it here
> because we talked about it on the call).
>
> Between #1 and #3 I would pick #1 for
simplicity, along with some
> warnings in the text. If we get real-life
experience that this is a
> problem (during interop) then we can switch
to #3 at that point.
>
> Thoughts?
>
> Regards,
>
> William