[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notification Schema Bug

Sharon Chisholm wrote:

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



The problem is that the default namespace is used incorrectly.

It is a good idea to set the default namespace (xmlns="foo")
to the target namespace (targetNamespace="foo") so definitions
within the module that reference other definitions from that
module are the only ones without a prefix.

The
It is important that the replayCompleteNotification be defined
as a complexType, to allow proper extensions for those vendors that
might ever want to do that (maybe even the WG).


Why can't you take the 'replayComplete' element and make it a ReplayComplete
complexType instead, so the element 'replayComplete' is a separate definition?

Can you see if the following fix works:

------------------------
--> Set the default namespace to the target namespace

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


--> In a different XSD:
  --> set the default namespace to the target namespace
  --> set the 'notif' prefix to the target namespace from the previous module

The replayCompleteNotification can be defined in another XSD and namespace:

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

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

-------------------------------------------------------------


[Note changes in 'base' and 'substitutionGroup' QNames]

Andy




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





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