Re: XMLCONF usage guidelines are flaw

[Larry Menten <lmenten@lucent.com>]

Faye,

Yes, that would seem to be the consequence of embedding both the
operation flags, target tree, and provided or returned value in the same
single argument.

The standard XML representation for opaque binary data is RAD64 (base 64)
and the encoding and decoding functions are provided in the XML library
(Xerces, for example.)  Using this would require that the binary 
structure be
well specified.  SNMP uses such an approach for OSPF LSAs but uses a
binary rather than asciized representation.  The layout of the LSA is as 
specified
in the OSPFv2 RFC.

Larry

Faye Ly wrote:

> Keith,
>
> I am afraid given the nature of XML and BEEP, that pretty much rule out the possibility of transporting binary data.  CRC checksum is a good example, you have to ASCII'fy it first.
>
> -faye
>
> -----Original Message-----
> From: Allen, Keith [mailto:kallen@tri.sbc.com] 
> Sent: Thursday, May 08, 2003 1:25 PM
> To: 'Larry Menten'; xmlconf
> Subject: 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/>