[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is DOM vs SAX a red herring?
Phil Shafer wrote:
Larry Menten writes:
- Attributes have their own namespace conventions that work quite well.
The attributes namespace conventions were designed for backwards
compatibility with DTDs are and don't follow the same conventions
are elements names. I don't see their current behavior as optimal
and have seen many folks get surprised by it.
Even with the requirement that a prefix be used to qualify attribute
values, the
result still only requires half as many characters to express, is still
easier to read,
and still carries more information (object vs. characteristic,
singleton attribute,
vs. multiple instance object).
- You have not yet offered a realistic expression that cannot be conveniently
expressed as an attribute value. So what is this vaunted "extensibility?"
The case of interest is where a simple boolean or statement evolves
to contain a hierarchy of statements.
<foo xmlns="http://example.org/foo/1.0">
<bar/>
</foo>
<foo xmlns="http://example.org/foo/1.1">
<bar>
<baz/>
</bar>
</foo>
Not a good example. Something that is a characteristic/attribute does
not magically
become an object. If "bar" were "area" or "interface" , it would never
have been expressed
as an attribute in the first place.
Do you have a real example?
This is fairly typical configuration evolution for us.
That said, the elements.vs.attributes debate has raged for years
and is not likely to be settled here. My take is that the extensibility
of elements wins over the brevity of attributes, but for any specific
data set, there's nothing to prevent one from using attributes instead.
As far as DOM vs. SAX is concerned. The data always has to go somewhere.
Just to be clear, the use of elements does not imply the use of
DOM. They are distinct choices.
But the use of elements does require that the parsed elements be cached
until enough
information has been collected to parse them. Except for trivial
examples, this means that
you will be allocating memory dynamically to store these until you have
collected enough
elements to identify and configure the target object.
Less efficient, less robust, more code.
The bottom line is
that the Enns document does not describe a protocol that is practical
for small devices.
I strongly disagree. The memory footprint for all of Junoscript is
insignificant. The footprint of the XML parsing bits are trivial.
Insignificant, perhaps, on a core router running BSD4. Very
significant on a SOHO device
running an embedded operating system. Shall we compare real numbers?
How much code is required to create and fully configure an OSPF
interface in the JUNOS
implementation, including any tables that must be configured to
validate the request?
If I understand your argument correctly, the only difference is
keeping the contents of your elements in some internal form
between the parents open tag and its close tag:
<interface" name="135.104.52.3" hello-interval="10"/>
<interface>
<name>135.104.52.3</name>
<hello-interval>10</hello-interval>
</interface>
In the first case, your sax parser is retaining the attribute values.
In the second case, your content handler must do it. There is no
impact on footprint or praticality.
You have provided just the leaf. With JUNOS you must retain the
entire tree in memory:
<configuration>
<protocols>
<ospf>
<area-list>
<area>
<interface-list>
<interface>
yada, yada, yada
To parse JUNOSSCRIPT you must store thousands to tens of thousands of
bytes
of information from the tree temporarily in memory. This is true
whether you use SAX or DOM.
That is the consequence of avoiding attributes.
You have a very big and unpredictable footprint.
I am storing just the name, namespace ID, and attribute list for one
single element.
I have a very small, predictable footprint.
Thanks,
Phil
Thanks,
Larry
--
Larry Menten Lucent Technologies/Bell Laboratories
Phone: 908 582-4467 600 Mountain Avenue, Murray Hill, NJ 07974 USA