Folks,
WRT last week's call on WSRF BP interop.
[I put the coders in the "To:" list, as they are the primary suspects of having to implement changes ...]
I have been digging (can't help it ...) and finally found what I think is the answer to our "QName problem". The documents I am referring to are:
1) "Namespaces in XML"
World Wide Web Consortium, 14 January 1999
2) "Namespaces in XML 1.0 (Second Edition)"
W3C Recommendation from 16 August 2006
In short:
WS-Notification is plain wrong, as it requires namespace declarations to be in scope for character data, opposing both documents.
In detail:
Document 2 is an update of document 1; I refer to both documents to demonstrate that namespaces - particularly namespace declarations and namespace scope(!) - are defined as such since 1999, predating WS-Notification.
Chapter 6 of document 2 is more or less a verbatim copy of chapter 5 in document 1. Hence I will refer to document 2 only from now on.
The whole document 2 deals with namespaces; only chapter 6 deals with namespace scoping. Particularly section 6.1 defines the scope of namespaces. The most important sentence in that section is the 2nd paragraph:
"Such a namespace declaration applies to all element and attribute names
within its scope whose prefix matches that specified in the declaration."
In other words, namespaces are IN SCOPE for all child elements and attributes, but NOT IN SCOPE for all possibly appearing character data.
Therefore, WS-Notification requires a parsing methodology which violates this W3C Recommendation.
Proposed solution:
We cannot force implementations that use tooling conforming to the referenced W3C Recommendation to change the tooling (or overriding it) to be non-conformant to XML Namespaces.
Therefore, I propose the following to the OGSA-WG:
a) Define a OGSA-WG dialect for Notification topics which is congruent to the "SIMPLE" dialect.
b) Define a XML Element of type xs:QName to carry the QName of the topic a client wants to subscribe to.
c) Mandate that, when a client uses the OGSA-specific dialect, that the OGSA-specific element MUST be present in the wsn:NotificationTopic element in the subscription request
---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP ----------
...
<ogsa-bp:TopicName>bp-interop:Ticker</ogsa-bp:TopicName>
<wsn:TopicExpression>
...
---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP ----------
This way, all implementations MUST respect the namespace scope, and any deserialiser for the ogsa-bp:TopicName element MUST de-reference the prefix correctly.
Side note to Query Resource Properties support:
The same holds to for the support for the QueryResourceProperties operation - as the namespaces are not in scope for the XPath expression (which is encoded as a String), there is no way for an implementor (unless violating XML Namespaces) to reliably de-reference prefixes used in a XPath expression unless the message carries explicit namespace-to-prefix information (other than the streamlined xmlns:prefix attributes). Which is, unfortunately not true for neither QueryResourceProperties nor WS-Notification's XPath dialect...
Process question (mostly to Hiro):
Given we agree on my proposal (or something similar) - is it possible to change the WSRF BP before it advances to the Recommendation status (after having the Experience doc written)?
Cheers,
Michel