Re: element order error processing

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> Hi,
> 
> I am confused as to which error-tag to use for wrong element order.
> 
> For example:
> 
> Given a simple data model:
> 
> element foo {
>    element a,
>    element b,
>    element c
> }
> 
> The use of missing-element vs. unknown-element error-tag is confusing:
> 
> Given this PDU fragment:
>  
>   <foo>
>      <a/>
>      <c/>
>   </foo>
> 
> It is clear that a 'missing-element' error for "/foo/b" should
> be generated here.
> 
> 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.

> in this case, which is totally confusing because "b" is not unknown
> at all.

Actually, unknown-element is defined as "An unexpected element is
present".  So it just says that the element is "unexpected" not that
it actually is "unknown".

> Generating a 'missing-element' and 'unknown-element' for "b"
> in the same <rpc-reply> is even worse.
> 
> What should the correct error response be in this case?

I think missing-element for /foo/b and unknown-element for /foo/c are
equally good (or bad).

However, your implementation could use an error-app-tag to further
describe this situation, if you can detect it.

> Is an agent implementation allowed to ignore wrong-order errors
> or must all elements always be given in a fixed order?

This must be depending on the data model.  A data model could be
defined with a strict order or not.  (compare w/ xs:all in a
complexType in XML Schema).



/martin

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