Notification XSD Bugs (2nd try)

[Andy Bierman <ietf@andybierman.com>]

Hi,

Here is the XSD snippet from RFC 4741 for the <rpc> element:

    <!--
      <rpc> element
      -->
    <xs:complexType name="rpcType">
      <xs:sequence>
        <xs:element ref="rpcOperation"/>
      </xs:sequence>
      <xs:attribute name="message-id" type="messageIdType"
        use="required"/>
      <!--
        Arbitrary attributes can be supplied with <rpc> element.
      -->
      <xs:anyAttribute processContents="lax"/>
    </xs:complexType>
    <xs:element name="rpc" type="rpcType"/>


    <!--
      rpcOperationType: used as a base type for all
      NETCONF operations
      -->
    <xs:complexType name="rpcOperationType"/>
    <xs:element name="rpcOperation"
                type="rpcOperationType" abstract="true"/>


As I pointed out in my email on May 4th, the <notification>
XSD definition MUST be in the same form as the <rpc> element,
in order to support 'substitutionGroup' replacement of the
one abstract element (ala 'rpcOperation'). 

The form of a NETCONF notification is:

<notification>
  <specificNotificationType>
    <specificNotificationContentNode>*
  </specificNotificationType>
</notification>

There must be an abstract element (only child of <notification>)
to specify the 'specificNotificationType' node.

The notification contents are defined by the specific notification type,
just as the RPC parameters are defined by the specific RPC operation.
The <rpc> template is the correct one to use, not <rpc-reply>.


Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>