[ogsa-wg] Fwd: WSRF BP Interop and WS-Notification QName issue (was: Re: Globus team will join next week or so)

[Michel Drescher]

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 at uk.fujitsu.com>
> Date: 8 April 2008 15:57:56 BST
> To: Mark Morgan <mmm2a at virginia.edu>, Rachana Ananthakrishnan <ranantha at mcs.anl.gov 
> >, Shiraz Memon <a.memon at fz-juelich.de>, Vivian Li <Vivian.Li at uk.fujitsu.com 
> >
> Cc: David Snelling <david.snelling at uk.fujitsu.com>, Hiro Kishimoto <hiro.kishimoto at jp.fujitsu.com 
> >, "A.S.McGough" <asm at doc.ic.ac.uk>, Andrew Grimshaw <grimshaw at cs.virginia.edu 
> >, Andreas Savva <andreas.savva at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20080501/d80b0cb5/attachment-0001.html