[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is DOM vs SAX a red herring?

Phil,

- Attributes have their own namespace conventions that work quite well.

- You have not yet offered a realistic expression that cannot be conveniently
    expressed as an attribute value.  So what is this vaunted "extensibility?"

- And why is replace="replace" better than op="replace"? Don your way,
  you must now verify that the attribute list does not also contain delete="delete",
  add="add", etc.

Why not use XML rather than fight it?

As far as the motivations for XML are concerned,  one of these
motivations is the ability to read the and create the representation
directly.  Don't confuse the willingness to compromise on brevity
with a willingness to forsake intelligibility.  I have translated your
example for intelligibility:

<configuration xmlns="http://...">
  <protocols>
    <ospf>
      <export op="insert-before" name="bar" value="foo"/>
      <area active="inactive" name="0.0.0.1"/>
      <area name ="0.0.0.0">
         <interface op="replace" name="135.104.52.3" hello-interval="10"/>
         <interface op="delete" name="135.104.52."/>
      </area>
    </ospf>
  </protocols>
</configuration>

As far as DOM vs. SAX is concerned. The data always has to go somewhere.
But not into a dynamically-allocated, bloated DOM tree.  The bottom line is
that the Enns document does not describe a protocol that is practical for small devices.
That is a significant failure.

Larry

Phil Shafer wrote:
Karl Auerbach writes:
  
(by-the-way, I'm leaning towards the "few attributes/more elements" side
of the discussion.)
    

Most of the guidelines in the draft are written based on
experience with Junoscript.  Basically the motivation is:

- attributes do not follow namespace conventions
- attributes lack the extensibility of elements
- operations on data often require modifiers or metadata
  for which attributes are invaluable

For us, the guideline of 'data as elements and modifiers
as attributes' has worked well.  Consider this example:

<configuration xmlns="http://xml.juniper.net/junos/5.4I0/junos">
  <protocols>
    <ospf>
      <exports>
        <export insert="before" name="bar">foo</export>
      </exports>
      <areas>
        <area active="inactive">
          <name>0.0.0.1</name>
        </area>
        <area>
          <name>0.0.0.0</name>
          <interfaces>
            <interface replace="replace">
              <name>135.104.52.3</name>
              <hello-interval>10</hello-interval>
            </interface>
            <interface delete="delete">
              <name>135.104.52.2</name>
            </interface>
          </interfaces>
        </area>
      </areas>
    </ospf>
  </protocols>
</configuration>

Elements are a long-hand form, but no one is looking at xml for its
brevity.

Early on, we considered making the use of attributes and elements
arbitrary, allowing a client to use whichever form suited them, but
never got 'round to coding it. Given the way we're used attributes,
this was probably a good thing.

But as Rob said, perhaps these guidelines should be removed or moved
to an appendix or something. They are intended as aids, not rules.

  
If one is doing that kind of evaluation of the proposed configuration data
- and I suggest that any device that doesn't do it is taking quite a risk
- then there will be a time when most of the proposed configuration data
is going to have to be simultaneously resident in memory.
    

Yup, we use the candidate configuration database for this, but the
data definitely has to go somewhere.

Thanks,
 Phil

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

-- 
Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA