Guys, as per last OGSA call on WSRF BP interop I was appointed to forward my proposal, which I originally sent only to the interop participants, to the whole OGSA Mailing list. The mail is very technical, and deals with found shortcomings in WS- Notification and hence OGSA WSRF BP 1.0, too. I would like to put up my proposal to the WG as a whole - so please read, (try to understand), and make comments. If you feel it is appropriate please feel to forward to relevant discussion groups, too (e.g. project specific mailing lists such as for UNICORE, Globus, etc.) Cheers, Michel Begin forwarded message:

From: Michel Drescher <Michel.Drescher@uk.fujitsu.com> Date: 8 April 2008 15:57:56 BST To: Mark Morgan <mmm2a@virginia.edu>, Rachana Ananthakrishnan <ranantha@mcs.anl.gov

...

, Shiraz Memon <a.memon@fz-juelich.de>, Vivian Li <Vivian.Li@uk.fujitsu.com

Cc: David Snelling <david.snelling@uk.fujitsu.com>, Hiro Kishimoto <hiro.kishimoto@jp.fujitsu.com

...

, "A.S.McGough" <asm@doc.ic.ac.uk>, Andrew Grimshaw <grimshaw@cs.virginia.edu , Andreas Savva <andreas.savva@jp.fujitsu.com> Subject: WSRF BP Interop and WS-Notification QName issue (was: Re: Globus team will join next week or so)

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 http://www.w3.org/TR/1999/REC-xml-names-19990114/

2) "Namespaces in XML 1.0 (Second Edition)" W3C Recommendation from 16 August 2006 http://www.w3.org/TR/REC-xml-names/

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

If, for example, the dialect name would be defined as "http://www.ogf.org/ogsa/2008/04/wsrf-bp/notification/simple " and the OGSA-specific element would be defined as "<element name="TopicName" type="xs:QName" /> then an example subscription message for the interop testing could look lime this:

---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP ---------- ... <wsn:TopicExpression dialect="http://www.ogf.org/ogsa/2008/04/wsrf-bp/notification/simple "> <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