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

Re: Back to elements and attributes Was Re: Is DOM vs SAX a red herring?



Karl Auerbach wrote:
On Mon, 12 May 2003, Larry Menten wrote:

  
There is no general rule that attributes be used "primarily as 
modifiers."  For example:
http://xml.coverpages.org/elementsAndAttrs.html
    
...
  
.. Elements are logical units of information in a 
schema. They represent information objects... Attributes are atomic, 
referentially transparent characteristics of an object that have no 
identity of their own.
    

  
Use elements for Objects.  Things such as "interface" or "area."
Use attributes for atomic things, such as the attributes of an object:  
"hello-interval", "name", ...
    

Much as that sounds good, I am still finding there to be uncertaintly.

Consider something like an on-off button.

It seems like it makes sense to give its state as an attribute... I mean, 
what could be more of an attribute whether it is up or down, on or off?
The state of the button is an attribute of something.  Perhaps as the on-off state of
a chassis element.
But on a lot of boxes that i've encountered lately, the on-off button is a
rather complex thing - The button is no longer binary, it has aspects such
as how long it has been pushed and thus may be a tri-state (or 
even a quad-state) thing.
When it becomes necessary to describe multiple attributes of a button, then it *might be*
useful to represent the button object and an element is introduced to represent the
button.  The button becomes a child of the chassis element and the newly introduced
button attributes are now attributes of the new element.

I personally find attributes to be really good for things that are so 
fixed and immutable that we know that they will never change, and elements 
for things that are more changeable.
That seems artificial.  The number of slots in an M10 chassis is fixed an immutable.  But the
element describing the chassis must also describe an m20 chassis.  And that chassis has it's
own "fixed and immutable" number of slots.
But as my example of the on-off button suggests, there are realms of 
flexibility in even the most simple seeming of things.

You could very reasonably suggest that I'm wandering into a rat hole here
- and I might be moved to agree with you if I were given a bit of
assurance that we are not locking outselves too tightly to a particular
model of how things are if we express certain relatively fixed aspects of
things as attributes.

To give a concrete example: Does turning an interface off on an interface 
on a switch also disable any 802.3af power-over-ethernet being fed out of 
that interface?
If the on/off state is remotely controlled, then you have a single control element that can make
multiple changes to the status of the device.  These might appear in response to a
get-status operation.  The on/off control might change the power-over-ethernet state, and/or the
color or lit/dark state of an indicator.  One control element.  Associated with the interface card.
Multiple status change results.

It seems to me that elements give us the flexibility to deal with that
kind of thing as they come up.  (It also makes me quake a bit in my shoes,
were I wearing shoes at this moment, about the ever-increasing issue of
having software that comprehends the full, or at least adequate, semantics
of things.)
Modeling reality is challenging.  That doesn't mean that we shouldn't attempt it.  I am sure you
have read and compared the various chassis MIBs.  What fun.  There are certain things
that need to be modelled identically across products.  Otherwise managing large collections
of devices from many vendors becomdes intractable.  But the element vs. attribute choice
is an orthogonal decision.  If we create a representation that is expensive to use, we will
have created the XML-equivalent of CMIP/CMISE.
		--karl--

Larry

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