Subject: element order error processing

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Feb 2006 09:20:51 -0800

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.  The only other
error choice seems to be  'unknown-element' for "/foo/b" in
this case, which is totally confusing because "b" is not unknown
at all.  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?

Is an agent implementation allowed to ignore wrong-order errors
or must all elements always be given in a fixed order?  This seems
like a CLR to me.

thanks,
Andy

--
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: Andy Bierman <[email-masked]>
Date: Sun, 12 Feb 2006 10:32:14 -0800

Martin Bjorklund wrote:
> Andy Bierman <[email-masked]> wrote:
>   
>> Hi,
>>
>> But "b" isn't missing, it is in the wrong place.
>>     
>
> We're generating 'missing-element' in this case.
>
>   

me too

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

Well, once I see that 'b' is missing, I bump the
current-node pointer to 'c', so it is not unexpected.

Since 'c' is last, the error code that looks for extra nodes will catch 
this,
and generate an (unexpected) unknown-element error for 'b'.

It's the combination that seems crazy, and yet also appears to be most 
correct,
at the same time.

>   
>> 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".
>   

I know -- I was trying to point out that our error codes are overloaded.

IMO, we will probably want to refine this sooner or later.
An application really wants to know the difference between:
 - agent doesn't know this node (maybe misspelled, or data model version 
mismatch?)
 - node is in the wrong order
 - more than the expected number of instances of a node are present

But the 'unknown-element' error-tag will be returned for all these error 
conditions.

>   
>> Generating a 'missing-element' and 'unknown-element' for "b"
> 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.
>   

Yes, I guess I will.
But this is not good enough for an interoperable standard.

>> 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).
>   

So it's up to the data modeling language, not XML itself?
That's what I was hoping.

So we don't HAVE to ignore the Postel Principle if we don't want to?

It really goes against common sense to reject an RPC with an error
like "parameter 2 and 3 are in the wrong order".  If the agent knows
all the parameters are present and accounted for,  that is good enough.
I'm not trying to force every agent to do this (I would say MAY, not MUST).

You may have noticed that CLI and Unix config file implementations
only enforce command order when they absolutely have to. 

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 12 Feb 2006 16:00:42 +0100 (CET)

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 13 Feb 2006 13:29:41 +0100 (CET)

> IMO, we will probably want to refine this sooner or later.

I agree.

> But this is not good enough for an interoperable standard.

I agree.  Currently we have 5 app-tags, all of them data modelling
specific.

> I'm not trying to force every agent to do this (I would say MAY, not MUST).

A well-defined order might be easier to implement - an agent might
have to buffer lots of data if the order is undefined.  We do not use
xs:all in our modelling language, i.e. we have a strict order.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Feb 2006 13:03:33 -0800

Martin Bjorklund wrote:
>> >....

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