RE: [wsn] WSN-Policy allocations reminder

[Matthew I Roberts <matt.roberts@uk.ibm.com>]

Hi William,

Thanks for your policy description.
I have had a good read through it and have some comments for discussion;

Firstly, I'm not sure that use of the
word "Transform" is good here - to me transform implies something
more than a simple subtree of the original message. I would normally expect
a transformation to be something like applying an XSLT, which can achieve
a significantly more dramatic change in the message than the subtree approach
that we are describing here. (perhaps XSLT-style transformation should
be a different policy?)

I'm not comfortable with the idea of
adding a new wrapper around the modifed content in the case of raw subscriptions.
My main scenario for raw subscriptions is for invoking existing non-WSN
aware web services based on the messageType of the application content.
Being able to subtree the message content could still be useful in this
case but not if we wrap the subtree element in a wrapper. I think that
the main reason for needing the wrapper is because you need to indicate
whether the NP understood (and took account of) this policy or not. In
the case where mustUnderstand=true there would be no need to add this new
wrapper in, because it is implicit that the content has been filtered as
requested, leading to me third query;

I would prefer to remove the mustUnderstand
semantics you describe in favour of the following approach; If the NP does
not understand (or is not willing to comply with) the policy statement
then it must fault. This is observed by the Subscriber, who can then re-issue
the subscribe request without the policy assertion if the NC is able to
accept the full message. This would help to solve the problem of wrappering
for raw notifications as described in the previous paragraph as well as
(imho) providing a cleaner model.

Thanks,

Matt


Matt Roberts
IBM WebSphere Messaging Design and Development
Hursley Park, England. +44 1962 815444
matt.roberts@uk.ibm.com
MP 211 / DE3H22

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

19/04/2006 22:49

To	Matthew I Roberts/UK/IBM@IBMGB, <wsn@lists.oasis-open.org>
cc
Subject	RE: [wsn] WSN-Policy allocations reminder

Hi Matt and all,
 
Here is my proposal, in the template
provided by map, for the policy statement assigned to me, selection of
a message subtree.
 
 
Description
Notification consumers might only be interested
in a portion of the notification message. In many cases, this is handled
at the consumer's side, by simply discarding the unwanted information.
But in some cases (for example if the notification messages are very large
and only a small subset is of interest to the consumer), it is advantageous
to have the transformation take place on the notification producer's side.
 
For this purpose, we define a "NotificationTransformPolicy"
policy element to advertise the fact that the notification producer provides
the ability to transform the message before sending it.
 
Options
The "NotificationTransformPolicy"
element has the following pseudo-schema:
<NotificationTransformPolicy ...>
  <SupportedDialect>xs:anyURI<SupportedDialect>
+
  <xs:any/> *
</NotificationTransformPolicy>
 
The "SupportedDialect" element
contains a URI describing a dialect supported by the notification producer
for transformation. The following dialect, "http://www.w3.org/TR/1999/REC-xpath-19991116",
represent use of XPath 1.0. Other dialects can be supported.
 
Context
Support for this policy is advertised by
the notification producer. This policy is invoked by the subscriber by
placing the "notificationTransform" header in the subscription
message. This header must be marked mustUnderstand=true of the consumer
is not prepared to handle notifications that were not transformed as prescribed
by the "notificationTransform" header.
 
The pseudo-schema of the "NotificationTransform"
header is:
 
<NotificationTransform dialect="xs:anyURI">xs:any</NotificationTransform>
 
The @dialect contains a URI describing the
dialect used to interpret the value of the "NotificationTransform"
element. That value can be text or any XML element. The "SupportedDialect"
children of the "NotificationTransformPolicy" element indicate
what dialects are supported by the notification producer.
 
If the notification message does not use
the "Notify" wrapper, the context for the transformation is the
body of the notification message. And the transformed message (including
the "TransformedNotification" wrapping) is placed in the SOAP
body. If the notification message uses the "Notify" wrapper,
the context for the transformation is the "wsnt:Message" element.
And the transformed message (including the "TransformedNotification"
wrapping) is placed in the "wsnt:Message" element.
 
In all cases, the modified notification payload
is wrapped inside a new element, called "TransformedNotification".
There is no expectation that the content of the "TransformedNotification"
element validate any schema, just that it is well-formed XML.
 
Example
Let's assume that the following message is
an example notification message:
 
<s:envelope>
  <!-- headers -->
  <s:body>
    <foo>
      <bar1>bar1value</bar1>
      <bar2>bar2value</bar2>
    </foo>
  </s:body>
</s:envelope>
 
If the subscribe message had included the
following header and if this header was accepted by the notification producer:
 
<NotificationTransform dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">/foo/bar2</NotificationTransform>
 
Then the notification message would instead
be:
 
<s:envelope>
  <!-- headers -->
  <s:body>
    <TransformedNotification>
      <bar2>bar2value</bar2>
    </TransformedNotification>
  </s:body>
</s:envelope>
 
The notifification producer can advertise
the following policy element to communicate the fact that it supports this
feature:
 
<NotificationTransformPolicy>
  <SupportedDialect>http://www.w3.org/TR/1999/REC-xpath-19991116<SupportedDialect>
</NotificationTransformPolicy>
 
Regards,
 
William