RE: Notification Schema Bug

["Sharon Chisholm" <schishol@nortel.com>]

Hi

I could not get this to validate. The XML Schema definition of the
replay complete didn't validate and neither did a random instance of a
notification that I tried. In the spirit of what Andy is suggesting, I
propose the same definition of notification, but the following
definition of the replay complete notification

    <xs:element name="replayComplete" minOccurs="0">
        <xs:annotation>
            <xs:documentation>
                This notification is sent to signal the end of a replay 
                portion of a subscription.
            </xs:documentation>  
        </xs:annotation>
        <xs:complexType>
          <xs:complexContent>
              <xs:extension
base="netconf:NotificationType"></xs:extension>              
          </xs:complexContent>
        </xs:complexType>
    </xs:element>

Instead of  

<xs:element name="replayComplete" minOccurs="0">
        <xs:annotation>
            <xs:documentation>
                This notification is sent to signal the end of a replay 
                portion of a subscription.
            </xs:documentation>  
        </xs:annotation>
    </xs:element> 


I can also define things like

    <xs:element name="fooNotification" >
        <xs:complexType>
          <xs:complexContent>
              <xs:extension base="NotificationType">
                  <xs:sequence>
                      <xs:element name="eventClass"/>
                  </xs:sequence>
              </xs:extension>  
          </xs:complexContent>
        </xs:complexType>
    </xs:element>

My validator lets me do a <get> on this, but I'm not sure how smart it
is.

Sharon
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Friday, May 04, 2007 8:19 PM
To: Netconf (E-mail)
Subject: Notification Schema Bug

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

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