OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrf] Discussion on issue 24



I would argue that #1 is the "right thing" as this is how namespaces work in xml; namely, anything declared on a parent element is in-scope for processing this element with closer declarations taking precedence over earlier ones.

Rich Thompson



"Vambenepe, William N" <vbp@hp.com>

08/09/2004 10:19 PM

To
<wsrf@lists.oasis-open.org>
cc
Subject
[wsrf] Discussion on issue 24






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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]