[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XMLCONF usage guidelines are flaw
Larry,
We added the guidelines to the draft because we felt it would
be useful to provide some direction in how the XML configurations
were structured.
Also, although using attributes is a definite win when parsing with SAX,
attributes don't play well with namespaces, versioning and
forward compatibility. As it says in the draft, attributes
are unordered, can only appear once, and have no children.
Anyway, these are just guidelines, if there's a strong objection to
them we can take them out (rather than enter a big debate about
what the guidelines should be), or implementors of configuration
syntax can ignore them (the beauty of guidelines).
thanks,
Rob
On Thu, May 08, 2003 at 11:45:35AM -0400, Larry Menten wrote:
> 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/>