Re: Is DOM vs SAX a red herring?

[Phil Shafer <phil@juniper.net>]

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