Subject: More feedback

From: Vincent Cridlig <[email-masked]>
Date: Tue, 07 Nov 2006 10:43:51 +0100

Hi,

I would like to share experience on XML data modeling for Netconf.

In the draft, there is currently an implicit difference of processing 
between elements and attributes. This difference is due to the way 
operations apply to the XML nodes. As far as I understand, all 
edit-config operations apply to XML elements, not directly to XML 
attributes. For example, you can replace an element, create an element 
or delete an element, but you can not directly delete an attribute, 
except by merging or replacing the whole element containing the attribute.

This has an impact on data modeling which can be both positive and 
negative. Let's take an example:

<distribute-list access-list="aclName" direct="in" ifname="eth0"/>

<distribute-list>
     <access-list>aclName</access-list>
     <direct>in</direct>
     <ifname>eth0</ifname>
****</distribute-list>

In the first version, all parameters are attributes of distribute-list. 
In this case, you have to deal with (1 element)*(4 operations) = 4 cases 
for edit-config.
In the second one, they are chidren of this element. In this case, you 
have to deal with (4 elements)*(4 operations) = 16 cases for edit-config.
Each time a new element is defined, you have to implement the four 
cases. Implementors will probably like to use the less elements as 
possible. Also it is less verbose to make large use of attributes.

A good practice could be to use attributes for both keys and required 
parameters. And to use elements for optional parameters. In this way, 
people are not tempted to delete required parameters, while still being 
able to change their values.

However, I also met other constraints. For example, I try to refactor 
our BGP, RIP and OSPF modules in order to stay as close as possible to 
Quagga CLI. (Quagga is an open source Linux daemon dealing with dynamic 
routing). In such case, I believe that it is a good practise to follow 
the command oriented context. Each command is one XML element and all 
parameters are attributes (like version 1 of the example). Each command 
which allows to change from one context to another has child elements 
which are the related sub-commands. Example:
<router type="rip">
    <redistribute source="kernel"/>
    <redistribute source="ospf"/>
    <network prefix="192.168.1.0/24"/>
    <passive-interface ifname="eth8"/>
    <passive-interface ifname="eth9"/>
</router>

Here each command can be deleted or created. So it follows our "best 
practises", except for the optional command parameters...

What I would like to highlight is that it is pretty hard to extract 
patterns for building a consistent XML data model. And I wondered if 
someone has such experience or comments, and if you have a case by case 
approach.

That was a pretty long email. Thanks for reading until here ! :-)

Regards,
Vincent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Nov 2006 11:05:55 +0100

On Tue, Nov 07, 2006 at 10:43:51AM +0100, Vincent Cridlig wrote:

> parameters.

The SMIv2 to XSD mapping of libsmi treats INDEX elements as attributes
and everything else as elements. I am not saying this is generally the
right approach, just that it was done this way for mapping SMIv2 to
XSD.

Phil keeps reminding us that attributes are "fun" with namespaces. Did
this cause problems to you?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
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: Vincent Cridlig <[email-masked]>
Date: Tue, 07 Nov 2006 11:55:17 +0100

> right approach, just that it was done this way for mapping SMIv2 to

This is what I would have done also.

> this cause problems to you?

The surprising thing about attributes is that they do not belong to any 
namespace except if you use an explicit namespace prefix, even if their 
parents have a namespace.
See http://www.rpbourret.com/xml/NamespacesFAQ.htm#q3_5

So I sometimes had some surprises with that, but once you know the 
solution, it is quickly solved.

Vincent