wsn message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsn] WSN-Policy allocations reminder
- From: "Vambenepe, William N" <vbp@hp.com>
- To: "Matthew I Roberts" <matt.roberts@uk.ibm.com>,<wsn@lists.oasis-open.org>
- Date: Mon, 8 May 2006 17:58:54 -0700
Thanks for the review Matt. See my comments
inlined.
William
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?)
<wv>I think XSLT, XQuery etc are very good candidate dialects for
this mechanism. I don't see why we would need another policy for these. I was
assuming that these would use that same policy, thus my choice of name. Can you
explain what the benefits of having a separate policy for these
be?</wv>
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;
<wv>You are right, we need to conserve this important use case for
unwrapped notifications and my proposal breaks this. The problem in removing the
wrapper is that the result of the evaluation of the expression might be more
than one element (e.g. in the XPath case you might end up w/ a nodeset
containing several elements - or even non-elements). One way to address this is
to have 2 XPath dialects, one that is constrained in such a way that the
resulting node set can contain only one element, and the other for which we do
use wrapping.
Another way to look at this, is potentially making use of the existing
wrapper in the spec. Actually, if you think about it, the wrapped notification
that we define is a case of transform. We could very well not have made this a
first-level concept but just created a dialect to represent it. Which brings up
the question of the order between the addition of the wrapper and the transform
(assuming we only allow one transform, which is my current assumption). In my
write-up I was assuming that the transformation was taking place after
application of the wrapper (if there is a wrapper). But we might want to reverse
this order. And explore whether the already-defined wrapper can be used in
cases where the transform returns more than one
element.</wv>
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.
<wv>"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". You're loosing me here. What you
are describing is exactly the behavior defined by must Understand. And in any
case, I don't understand how this helps w/ the wrappering
problem.</wv>
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]