Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:>.... What about this?: <foo> <a/> <c/> <b/> </foo> A reasonable implementation choice would lead one to generate a 'missing-element' error for "/foo/b" when "/foo/c" is encountered. But "b" isn't missing, it is in the wrong place.We're generating 'missing-element' in this case.The only other error choice seems to be 'unknown-element' for "/foo/b"I'd say that the other alternative would be unknown-element for /foo/c.
I see why you are doing this now.
Given this example:
<foo>
<a/>
<blah/>
<b/>
<c/>
</foo>
Advancing the 'current pointer' as I described before will
cause an incorrect unknown-element error for 'b' and 'c' in this case.
The most correct response in this example is one <rpc-error>
for unknown-element(blah).
I still think it is easier not to enforce a strict order.
Consider the error complexity when the previous example
grows up a tiny bit:
element {
element a?,
element b*;
element c*,
element d?
}
Now checking for strict order is even harder.
Throw in some 'choice' clauses, and even harder.
I'm not trying to change the protocol spec.
This is a data model matter after all.
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/>