[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: notification-07 issue list (4 & 5)
Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:
The current XSD definition is for a <notification> wrapper
that cannot have any XML attributes defined, and must contain
an element called <data>.
<xs:complexType name="dataInlineType">
<xs:complexContent>
<xs:extension base="xs:anyType"/>
</xs:complexContent>
</xs:complexType>
<!-- <Notification> operation -->
<xs:complexType name="NotificationType">
<xs:sequence>
<xs:element name="data" type="netconf:dataInlineType" />
</xs:sequence>
</xs:complexType>
<xs:element name="notification" type="NotificationType"/>
The <replayComplete> notification does not have an element called <data>.
This may not be the only notification ever defined that does
not have any additional data to include.
I think the idea is that a notification looks like this:
<notification xmlns="urn:ietf:params:netconf:capability:notification:1.0">
URN is wrong! Use the Namespace format, not the Capability format.
<data>
<my-notif xmlns="http://example.com/ns/foo">
...
</my-notif>
</data>
</notification>
Can you find some examples on the mailing list where this sort
of structure is used?
I think we have been assuming the following format, as we agreed to
for the <replayComplete> notification:
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification">
<replayComplete xmlns="urn:ietf:params:xml:ns:netmod:replayComplete"/>
</notification>
There are no examples of what a <notification> looks like though.
The <data> element does seem to be superflous though.
I think this approach works, although an alternative is to use a
subsitution group like the rpc, which you pointed out earlier.
I don't see why the extra XML layer helps.
/martin
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/>