[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: XMLCONF usage guidelines are flaw



Larry Menten writes:

For an example, the following representation of OSPF configuration
is compact, allows the XML parser to enforce the uniqueness of attributes
of the configuration elements and can be compactly parsed within the device
using a very compact implmentation of a SAX parser:

<ospf id="135.104.52.1">
    <area id="0" type="nssa">
       <interface id="135.104.52.3" helloInterval="10" deadInterval="40"/>
       <interface id="135.104.54.2" helloInterval="10" deadInterval="40"/>
    </area>
</ospf>

...

If the area element had an "attribute" that could not be expressed by a
simple text string, then and only then would you include it as a sub
element?  For example, suppose we wanted to represent IP addresses with a
special syntax instead of a text string, how would you accommodate that?


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com
 


-----Original Message-----
From: Larry Menten [mailto:lmenten@lucent.com] 
Sent: Thursday, May 08, 2003 10:46 AM
To: xmlconf
Subject: XMLCONF usage guidelines are flaw

I have examined the guidelines provided in the
Enns XMLCONF draft and I believe they
impose to great a cost on the processing of the
XML configuration content.  In particular, the
statement "attributes should contain metadata
about the element, not true data."  I believe that this
is a misapplication of XML that results in a cumbersome
representation that is costly to process.  This in turn
results in greater development cost and greater cost
of device resource.  Further, I see no
compelling reason to create artificial elements to create lists.
This is simply an artifact of the use of elements to represent
scalars when, in my view, an attribute would be more appropriate.

For an example, the following representation of OSPF configuration
is compact, allows the XML parser to enforce the uniqueness of attributes
of the configuration elements and can be compactly parsed within the device
using a very compact implmentation of a SAX parser:

<ospf id="135.104.52.1">
    <area id="0" type="nssa">
       <interface id="135.104.52.3" helloInterval="10" deadInterval="40"/>
       <interface id="135.104.54.2" helloInterval="10" deadInterval="40"/>
    </area>
</ospf>


 The Enns guidelines would have us write:

<ospf>
  <id>135.104.52.1</id>
  <area>
     <id>0</id>
     <type>nssa</type>
      <interfaces>
           <interface>
               <id>135.104.52.3</id>
                <helloInterval>10</helloInterval>
                <deadInterval>40</deadInterval>
            </interface>
           <interface>
               <id>135.104.54.2</id>
                <helloInterval>10</helloInterval>
                <deadInterval>40</deadInterval>
            </interface>
       </interfaces>
    </area>
<ospf>


This is less expressive of intent.  Painful to create by hand.
Difficult to visually parse.

It is more efficient to process this as a DOM tree than as
SAX events.  I would contend that the reusable code is larger,
the non-reusable code is much larger and the resulting code is more
error prone, less robust.

Larry

-- 
Larry Menten   		    Lucent Technologies/Bell Laboratories
Phone: 908 582-4467         600 Mountain Avenue, Murray Hill, NJ  07974 USA

 



--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>

--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>