Re: draft-shafer-netconf-syslog-00.txt

[Phil Shafer <phil@juniper.net>]

Andy Bierman writes:
>  <rpc-reply> element in the netconf NS
>    <rpc-error>*    - Zero or more <rpc-error> elements in the netconf  NS
>    <data>?         - Zero or one <data> element in the netconf NS, which
>                      can contain zero or more XML elements from any namespace,
>                      or no namespace at all.
>  </rpc-reply>

The text in netconf-prot does not constrain the top level element
of the reply, nor does it mandate that it be under a <data> element.

   The response name and response data are encoded as the contents of
   the <rpc-reply> element.  The name of the reply is an element
   directly inside the <rpc-reply> element, and any data is encoded
   inside this element.

Unfortunately, the xml schema does constain the reply to <data>.
So the question is: can we correct the schema?
 
><rant>
>In a standard, consistency and interoperability are far more
>important than saving the 13 bytes on the wire that the <data>
>element represents.

<taking-the-bait>
I fail to see how the existence of the <data> element does anything
to improve consistency or interoperability.  It's just a noise word
that we'll be stuck putting in rpc replies, xpath expressions and
sax filters for the rest of our lives, unless we can fix it now.

Thanks,
 Phil

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