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

Re: XMLCONF usage guidelines are flaw

Faye,

By syntax.  In my examples, I used the attribute "id" to represent
a single component key field.  Where it has an IP address value,
that could be v4 or v6 one could use the colon-embedding syntax
for v6 and the dot-embedded syntax for v4.  If the address version is
represented by the syntax, then is is necessary to record within the managed
entity what type of address was provided so that internally the proper
filed is used and so that serialization (get-request) works properly.
OSPF areas can be identified by either an ipv4 address or a 32-bit unsigned integer.
A single internal field is sufficient since they both map to a 32-bit unsigned
value, but the type of id used must be remembered so that a get-request
encodes the value properly as an unsigned in or in dot-notation.

In OSPFv2 the addresses can only be v4 so there is not issue.

In some contexts it might be necessary to provide both v4 and v6 addresses.
 Using a separate attribute name for each that indicates the type of address is our approach.

The use of the attribute name "id" for a single component key has proven useful
in creating very compact SAX-driven management code.  We also support
multiple attribute keys with arbitrary names, but the attribute names must then
be known to the facade classes that parse the attribute list.  One more element-specific
thing that must be included in the code.

Larry


Faye Ly wrote:
Larry,

How do you tell the difference between IPv4 and IPv6 addresses?  Is it
by length?  

-faye

-----Original Message-----
From: Larry Menten [mailto:lmenten@lucent.com] 
Sent: Friday, May 09, 2003 7:29 AM
To: Allen, Keith
Cc: xmlconf
Subject: Re: XMLCONF usage guidelines are flaw

Keith,

Could you provide a realistic example of an attribute that
cannot be expressed as an attribute value?

Larry

Allen, Keith wrote:

  
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