Re: Semantics and the classic argument: elements vs attributes

Greetings Shane, I think that the subject line doesn't fully cover what 
you are discussing. There is the age old debate between elements and 
attributes but there is the additional dimension of their values, 
particularly attribute values. While discussing principles is useful it 
can also become a sterile debate. With that in mind I would like to 
explore what you have raised using the concrete example that started this 
thread.

The genesis was a question from Dustin Boyd [1] "Do we really need four 
different types of lists in XHTML 2.0?" We discussed for a while and felt 
that the three that are already in (X)HTML were fine but were not so sure 
about the new one : <nl /> .

I cannot locate the original requirement that led to the creation of <nl 
/> but I imagine it would have been something like the need to clearly 
identify that a particular segment of a web page purpose for existence was 
to gather together constructs related to navigation (links).

This is a common requirement and number of solutions have been arrived at 
in various groups. The XHTML Role Vocabulary defines a value "navigation" 
for use with the @role. This attribute can be applied to any element. The 
aforementioned <nl /> (part of XHTML 2) defines an ordered list of items 
for navigation purposes. The <nav />  (part of HTML 5) defines a 
specialised section for the navigation/linking purpose.

Something that I have not found is an attribute for this purpose though it 
would be easy to imagine something like <section navigation="primary">.

Perhaps this example allows us to develop a principle but I would like to 
make sure that a specific answer to the question of how to handle 
navigation is arrived at. My personal view is that a section is a better 
container than a list, though I concede that the section will most likely 
contain a list. I prefer <nav /> to <nl /> since it suits the scenarios I 
have explored before, particularly when adapting content to different 
devices.
  
[1] http://lists.w3.org/Archives/Public/www-html/2008May/0005.html 

Regards, Roland



From:
Shane McCarron <shane@aptest.com>
To:
XHTML WG <public-xhtml2@w3.org>
Date:
20/11/2008 16:43
Subject:
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










Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU