Notification Schema Bug

[Andy Bierman <ietf@andybierman.com>]

Hi,

The notification element definition is obsolete, based on the
decision to remove the parameters from the ReplayCompleteNotification.
There is no <data> element in the notification, like <rpc-reply>.
The <notification> element is a wrapper, just like the <rpc> element.
This allows proper extension by any organization.  The XSD for
the <notification> element must be done the same way as the <rpc> element.

Current text: notification-06: page 21:

    <xs:complexType name="NotificationType">
       <xs:sequence>
         <xs:element name="data" type="netconf:dataInlineType" />
       </xs:sequence>
    </xs:complexType>

    <xs:element name="notification" type="NotificationType"/>


Proposed replacement text for page 21:

    <xs:complexType name="NotificationContentType"/>

    <xs:element name="notificationContent"
                type="NotificationContentType" abstract="true"/>

    <xs:complexType name="NotificationType">
      <xs:sequence>
        <xs:element ref="notificationContent"/>
      </xs:sequence>
    </xs:complexType>

    <xs:element name="notification" type="NotificationType"/>


The replayCompleteNotification can be defined in another XSD and namespace:

    <xs:complexType name="ReplayCompleteNotificationType">
      <xs:complexContent>
        <xs:extension base="NotificationContentType"/>
      </xs:complexContent>
    </xs:complexType>

    <xs:element name="replayCompleteNotification"
                type="ReplayCompleteNotificationType"
                substitutionGroup="notificationContent"/>


Of course, a notification with parameters would not have an empty 
<extension>
like this one.


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/>