Re: [ba-ohs-talk] Fwd: [xml-dev] Penance for misspent attributes

[Eric Armstrong <eric.armstrong@sun.com>]

Sandy Klausner wrote:    (01)

> > "Another way of thinking about elements and attributes is to think
> of
> > an element as a container. To reason by analogy, the contents of the
>
> > container (water or milk) correspond to XML data modeled as
> > elements. On the other hand, characteristics of the container (blue
> > or white, pitcher or can) correspond to XML data modeled as
> > attributes. Good XML style will, in some consistent way, separate
> > each container's contents from its characteristics."
>
> Try this concept ...
> An element is declared as a schema container and its value is
> invariant from one document instance to another during execution.
> Whereas, an element's structure is composed of attributes that have
> variant value.
> Sandy    (02)

I think the notion of variance and invariance is an important one to
observe,
in this respect, but I don't follow your description of it.    (03)

Using my analogy, the pitcher's contents may vary, while the pitcher's
color
is an invariant. So an element is used for changable content in the
container,
while an attribute is used for an invariant aspect of the container.    (04)

Using an IBIS-kind of example, we might have
      <node type="question" category="performance">
             <content>How do we get enough speed</content>
             <node type="alternative" category="hardware">
                   <content>We use a bigger computer</content>
              </node>
       </node>    (05)

Or something to that effect. The interesting observation here is that if    (06)

the meta data for a node is held invariant, then the content of a node
is restricted -- only changes that preserve the node's semantics are
allowed (or at least considered "good form").    (07)

To make that concrete, here is another IBIS example:
     <node type="argument" category="pro">
          <content>I lik this idea</content>
     </node>    (08)

Fixing the typo from "lik" to "like" would maintain the node's
semantics (a pro argument), so that change could reuse the
node. But changing the text to "I *don't* like this idea" would
change the node's semantics. If the node's meta data is held
invariant, than doing that edit would result in a "pro" node that
contained a "con" argument. Not good! For the meta data to
reflect the contents, a new node would have to be created.    (09)

But that is a way cool thing, because it solves a problem we were
discussing a few weeks ago, of how to decide when a link should
go to the latest version of a node, and how to know when a change
conceptually represents a "fork", such that the link should continue
to go to the old node.    (010)

The answer lies in the meta data. We can specify as a heuristic, in
fact, that the set of possible meta data values values is sufficient
if and only if any modification which changes the semantic content
of the node produces a conflict with the meta data on that node.
(Whether we can automatically detect such conflicts is another
matter. It would be nice, but not necessary for the value of the
heuristic.)    (011)

However, when you wrote "an element's structure is composed of
attributes that have variant value", I'm not sure what you mean.    (012)

In my view, attributes would be invariant -- and we derive a lot
of benefit from holding them invariant. I'm not sure if you simply
used the word unintentionally here, or if your original proposal
is something different from what I understood!    (013)