More feedback

[Vincent Cridlig <vincent.cridlig@loria.fr>]

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


begin:vcard
fn:Vincent Cridlig
n:Cridlig;Vincent
org:LORIA - INRIA Lorraine, France;Madynes
adr:;;;Nancy;;;France
email;internet:cridligv@loria.fr
title:PhD Student
tel;work:+33 (0)3 83 59 20 48
url:http://www.loria.fr/~cridligv
version:2.1
end:vcard