Re: [wsn] WSN Wording

[Peter Niblett <peter_niblett@uk.ibm.com>]

I think the bulleted approach is clearer, but I have a couple of comments
on the words

i) The "itself" at the end of the first bullet is confusing and unnecessary
(it looks as though it means that no-one else is allowed to produce the raw
message)

ii) You use the phrase "a child of the fault detail." here (and also in the
descriptions of the new faults). This is a SOAP-specific term, and as far
as I am aware we don't require WS-N implementations to use SOAP bindings.
Also the bigger phrase "a UnsupportedPolicyRequestFault message with a
wsnt:UseRaw element as a child of the fault detail " is ambiguous as a
reader has to decide the precedence rule between "with" and "as" . I first
read it as "UnsupportedPolicyRequestFault message with a (wsnt:UseRaw
element as a child of the fault detail) " - but since the
UnsupportedFaultMessage is a WSDL message and does not have a fault detail,
I assume what you meant was "(UnsupportedPolicyRequestFault message with a
wsnt:UseRaw element) as a child of the fault detail) ". Moreover it's also
not 100% clear where the implementer is supposed to insert the useRaw (or
other unsupported/unrecognized policies) since our fault message
definitions,, although they extend BaseFault, don't include a place to put
it. Are you supposed to use the extensibility element in BaseFaultType?

I think you should just talk about the fault message here, so the words
become



      The presence of this element is interpreted as a request for raw
      Notification.  If raw notification is requested, then:
            If the NotificationProducer supports this form of notification,
            then the NotificationProducer MUST produce the raw Notification
            message.
            If the NotificationProducer does not support this form of
            notification, it MUST return an UnsupportedPolicyRequestFault
            message containing a wsnt:UseRaw element. The
            NotificationProducer MUST NOT return an
            UnrecognizedPolicyRequestFault  in response to this element.


      The absence of this element is interpreted as a request for
      notification using the wsnt:Notify wrapper.  If notification using
      the Notify wrapper is requested, then:
            If the NotificationProducer supports this form of notification,
            then the NotificationProducer MUST produce Notification
            messages using the Notify wrapper.
            If the NotificationProducer does not support this form of
            notification, it MUST return a NotifyMessageNotSupportedFault
            message.

We should also extend the two fault types to include a place to put the
policy, e.g.

  <xsd:complexType name="UnsupportedPolicyRequestFaultType">
      <xsd:complexContent>
            <xsd:extension base="wsrf-bf:BaseFaultType">
                  <xsd:sequence>
                        <xsd:element name="Policy">
                              <xsd:complexType>
                                    <xsd:sequence>
                                          <xsd:any namespace="##any"
                                                processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
                                    </xsd:sequence>
                              </xsd:complexType>
                        </xsd:element>
                  </xsd:sequence>
            </xsd:extension>
      </xsd:complexContent>
  </xsd:complexType>

(though it might be better to factor out the anonymous complex type here).

I don't understand your last sentence - what is the "extra step" you
mention? Is there some subtlety that I have missed?

Peter



                                                                           
             David Hull                                                    
             <dmh@tibco.com>                                               
                                                                        To 
             24/10/2005 18:43          wsn@lists.oasis-open.org            
                                                                        cc 
                                                                           
                                                                   Subject 
                                       [wsn] WSN Wording                   
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Shorter, more explicit, and mentions UnrecognizedPolicy.  What's not to
like :-)


      The presence of this element is interpreted as a request for raw
      Notification.  If raw notification is requested and the
      NotificationProducer supports this form of notification, then the
      NotificationProducer MUST produce the raw Notification message
      itself.   If the NotificationProducer does not support this form of
      notification, it MUST return a UnsupportedPolicyRequestFault message
      with a wsnt:UseRaw element as a child of the fault detail.  The
      NotificationProducer MUST NOT return an
      UnrecognizedPolicyRequestFault  in response to this element.


      The absence of this element is interpreted as a request for
      notification using the wsnt:Notify wrapper.  If notification using
      the Notify wrapper is requested and the NotificationProducer supports
      this form of notification, then the NotificationProducer MUST produce
      Notification messages using the Notify wrapper.   If the
      NotificationProducer does not support this form of notification, it
      MUST return a NotifyMessageNotSupportedFault message.
Well, actually, there is a dangling if/then/else:  The third sentence in
each paragraph could be misread as being unconditional, instead of
conditional on whether the given format was suggested (even though this
makes no sense in context).  Bullets may help:


      The presence of this element is interpreted as a request for raw
      Notification.  If raw notification is requested, then:
            If the NotificationProducer supports this form of notification,
            then the NotificationProducer MUST produce the raw Notification
            message itself.
            If the NotificationProducer does not support this form of
            notification, it MUST return a UnsupportedPolicyRequestFault
            message with a wsnt:UseRaw element as a child of the fault
            detail.  The NotificationProducer MUST NOT return an
            UnrecognizedPolicyRequestFault  in response to this element.


      The absence of this element is interpreted as a request for
      notification using the wsnt:Notify wrapper.  If notification using
      the Notify wrapper is requested, then:
            If the NotificationProducer supports this form of notification,
            then the NotificationProducer MUST produce Notification
            messages using the Notify wrapper.
            If the NotificationProducer does not support this form of
            notification, it MUST return a NotifyMessageNotSupportedFault
            message.
Obviously, these are this close to being variants of the same rule, but I
don't know if we need to take the extra step.  It would mean re-working
faults, again.  Perfect is the enemy of good enough.