Semantics and the classic argument: elements vs attributes

During the call Wednesday, there was a brief (re)discussion of whether 
we are smarter to embed semantics in elements, attributes, or attribute 
values.  This is an old argument, but it apparently still has a lot of 
heat.  I wanted to capture my opinions about this as a way of kicking 
off a discussion here rather than trying to do it during a call.  If we 
can get our positions clearly stated here, we may find that we are all 
in violent agreement.  I am not convinced this will happen, but it *could*.

Anyway, here is what I think.  XML and XHTML are designed to be extended 
at the element AND the attribute level.  In particular, XHTML M12N 
defines an infrastructure for integrating components into "hybrid" 
markup languages.  In general, we envisioned that those components would 
be developed by the W3C or other industry groups, not by individuals.  
Why?  Because it is not easy, and such extensions need definition by a 
group to make them viable, interesting, and most importantly *supported*. 

What do I mean by supported?  Anyone can define a new element or 
attribute.  Anyone can create a hybrid markup language that includes 
that element or attribute.  With CSS2 it is possible for us to define 
presentation rules for the element or selectors that switch on the 
attribute.  But even with all of that, no user agent will know what it 
*means*.  And there is no mechanism for the person defining this element 
or attribute to describe its meaning in a way that a smart, 
"follow-your-nose" user agent could use to even determine what it 
means.  So, if a new element or attribute is defined, it will not become 
meaningful until a complete new generation of user agents is deployed.  
And worse yet, if it is not defined by some group that user agent 
developers care about, then that new element or attribute will always 
have just as much meaning as "span" or "@title" - e.g., none at all.

To address this problem, we ALSO introduced dynamic semantic extension 
mechanisms through RDFa and @role.  The purpose of these mechanisms is 
to allow the declaration of characteristics of a document, and associate 
those characteristics with definitions that are machine discoverable and 
machine interpretable.  The ultimate result of this, when it is done 
right, is that a role value of "foo:bar" is a vocabulary term defined in 
some vocab space pointed to by "foo" that defines the MEANING of bar 
based upon common RDF terms, or upon other vocabs that use those common 
RDF terms.

So, we have two mechanisms.  Elements and Attributes.  Here's what I 
believe:

    * I believe that both mechanisms are important. 
    * I also believe that we, as a part of an industry group, have the
      wherewithal to define elements and attribute and declare their
      semantics knowing that they will be *supported* someday. 
    * I believe it is critical that we define new elements and
      attributes when that is what good design requires.  (e.g., in XML
      Events we could have done all the handler stuff with attributes. 
      We could have done RDFa with values of @class.  Those would have
      been bad design decisions.)
    * Finally, I believe that it is also critical that we ONLY use the
      attribute extension mechanisms when what we are doing is purely
      and generally semantic.  If what we are doing is at all
      structural, then we MUST NOT use the attribute extension
      mechanisms.  It overloads our existing elements AND it permits the
      use of the vocabulary terms anywhere - which is probably NOT what
      we want.

How does this apply practically?  I am afraid if I start drilling down 
to a specific element or attribute then we will get sidetracked by 
that.  I wonder if we could discuss this basic principle and see if we 
can agree on guidelines for when we define new elements or attributes, 
as opposed to when we would use our @role and RDFa extension mechanisms 
we would then have something we could use to test current and future 
decisions against.

Opinions?

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Thursday, 20 November 2008 16:43:08 UTC