Re: Is DOM vs SAX a red herring?

[Phil Shafer <phil@juniper.net>]

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.

>- 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>

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.

>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.

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.

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>