Subject: RE: Compact RELAX NG Schema for NETCONF

From: "Gilbert Gagnon" <[email-masked]>
Date: Tue, 16 Nov 2004 17:17:52 -0500

With a more readable schema comes understanding and therefore more
questions...;-)

One thing that I'm puzzled about here the association between the schema of
NetConf
(whatever language is used to describe it) and the concept of capability.
Capability allows one to extend the protocol in an open manner but
that seems to be contradicted the schema.  I note, for example, that the
schema below 
not only describes the base NetConf structures but also those introduced by 
optional capabilities (URL, candidate, ...).  
How can the schema know in advance all possible capabilities.
In fact, the schema even closes the door on them...  For example, one 
good idea (I wish was in the document itself but that's another story) is to
include
time-stamp information in the <ok> element.  The schema closes the door to
this
(and any capability extension in this direction) by mandating that the ok
element
is empty.

So how can the schema be as extensible as NetConf capabilities?

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Rob Enns
Sent: Tuesday, November 16, 2004 4:58 PM
To: [email-masked]
Subject: Compact RELAX NG Schema for NETCONF

Here is a RELAX NG schema for the NETCONF protocol in compact form. It was
created automatically from the XML form of the RNG schema.

thanks,
 Rob

----

default namespace nc = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace local = ""
namespace inh = inherit

message-id = attribute message-id { xsd:string }

session-id = element session-id { xsd:unsignedInt }

anyElement = element * { ( attribute * { text } | text | anyElement )* }

config = anyElement*

configName =
   element startup { empty }
 | element candidate { empty }
 | element running { empty }

url = element url { xsd:anyURI }

source = element source { config | configName | url }

target = element target { configName | url }

filter =
   element filter
   {
      attribute type { "subtree" | "xpath" }?,
      ( anyElement | text )?
   }

getConfigType = element get-config { source, filter? }

operation = attribute operation { "merge" | "replace" | "create" | "delete"
}

default-operation = element default-operation { "merge" | "replace" | "none"
}

test-option = element test-option { "test" | "test-then-set" | "set" }

error-option = element error-option { "stop-on-error" | "ignore-error" }

editConfigType =
   element edit-config
   {
      target,
      default-operation?,
      test-option?,
      error-option?,
      config?
   }

copyConfigType = element copy-config { source, target }

deleteConfigType = element delete-config { target }

getType = element get { filter? }

lockType = element lock { target }

unlockType = element unlock { target }

validateType = element validate { source }

commitType =
   element commit
   {
      element confirmed { empty }?,
      element confirm-timeout { xsd:unsignedInt }?
   }

discardChangesType = element discard-changes { empty }

closeSessionType = element close-session { empty }

killSessionType = element kill-session { session-id }

rpcType =
   getConfigType
 | editConfigType
 | copyConfigType
 | deleteConfigType
 | getType
 | lockType
 | unlockType
 | validateType
 | commitType
 | discardChangesType
 | closeSessionType
 | killSessionType

error-type =
   element error-type { "transport" | "rpc" | "protocol" | "application" }

error-tag =
   element error-tag
   {
      "TOO_BIG"
    | "MISSING_ATTRIBUTE"
    | "BAD_ATTRIBUTE"
    | "UNKNOWN_ATTRIBUTE"
    | "MISSING_ELEMENT"
    | "BAD_ELEMENT"
    | "UNKNOWN_ELEMENT"
    | "ACCESS_DENIED"
    | "LOCK_DENIED"
    | "RESOURCE_DENIED"
    | "ROLLBACK_FAILED"
    | "DATA_EXISTS"
    | "DATA_MISSING"
    | "OPERATION_NOT_SUPPORTED"
    | "OPERATION_FAILED"
    | "PARTIAL_OPERATION"
   }

error-severity = element error-severity { "warning" | "error" }

rpcErrorType =
   element rpc-error
   {
      error-type,
      error-tag,
      error-severity,
      element error-app-tag { text }?,
      element error-path { text }?,
      element error-message { text }?,
      element error-info
      {
         element bad-attribute { text }?,
         element bad-element { text }?,
         element ok-element { text }?,
         element err-element { text }?,
         element noop-element { text }?,
         session-id?,
         anyElement?
      }?
   }

rpcReplyType =
   element ok { empty } | rpcErrorType | element data { anyElement? }

helloType = element capabilities { element capability { text }+ }

start |= element rpc { message-id, rpcType }

start |= element rpc-reply { message-id?, rpcReplyType }

start |= element hello { helloType }

--
to unsubscribe send a message to [email-masked] with the word
'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Rob Enns" <[email-masked]>
Date: Tue, 16 Nov 2004 17:07:20 -0800

> Hm, do the specs not allow for warnings that go along with results?
> Do the specs not allow for multiple errors/warnings? I am having
> some general questions in this space (but I am not yet done reading
> the spec) - so I will probably post more later.

This is definitely a bug in both the XSD and RNG schemas.
The spec does allow (possibly multiple) errors/warnings to go 
along with results, at least that is the intent. It's not 
explicit about it, however, and it should be. Fixing...

thanks,
 Rob

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>