Re: [wsn] Issues Verification: 2.25, 2.36 and 2.53

[David Hull <dmh@tibco.com>]

This is a good point.

I think the underlying concern is that, while it is certainly possible
to support other resource views, this particular view is a unit.  For
example, if you support TopicExpression, you should also support
FixedTopicSet, and if you include any TopicExpression or
TopicExpressionDialect properties, they must mean what they say they
mean.  Clearly, the current text doesn't quite say that and needs to be
tweaked.

Patil, Sanjay wrote:

>I found the agreed approach for 2.36 and 2.53 being incorporated by the
>latest (j) version of the BaseN specification.
>
>Regarding 2.25, I have the following comment:
>
>This issue is about the normative dependency on WSRP and WSRL. One of
>the action items in this regard was to make it optional for the
>NotificationProducer to be a WS-Resource.
>
>The related text from the latest (j) version of BaseN reads as follows:
>------------------------------------------------------------------------
>----------------------
>In addition to the message exchanges described in this specification, a
>NotificationProducer MAY also support the required message exchanges
>defined in the WS-ResourceProperties specification and MAY support the
>optional message exchanges defined in the WS-ResourceProperties
>specification. If it does so, tthe Resource Properties document defined
>by the NotificationProducer MUST include a reference to the following
>resource property elements: ....
>------------------------------------------------------------------------
>----------------------
>
>My interpretation of the above text is that - If a NotificationProducer
>supports WSRP message exchanges, then it must support the resource
>properties defined by the BaseN specification. I don't think that was
>our intent. I don't think it is reasonable to prohibit a
>NotificationProducer from being a WS-Resource and supporting entirely
>different set of resource properties than the ones identified by BaseN.
>I think our intent was to say that, in addition to the bespoke methods
>defined by BaseN, a NotificationProducer may optionally support --
>access to a well defined set of resource properties via the WSRP
>protocol.
>
>Thanks,
>Sanjay
>
>
>  
>