[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XMLCONF usage guidelines are flaw
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
--
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/>