Re: Getting beyond the ping pong match (was RE: Cleaning House)

Henri,

> The point is exploring *if* they can be interpreted using existing
> practice as a guide. This is subtly different from just using a
> dictionary: if research showed that a non-word string was
> consistently used to denote something useful, a dictionary would not
> have to be involved. Since it is improbable that the string
> "copyright" would appear accidentally without someone thinking of the
> concept of copyright while writing the string, it is reasonable to
> assume that the string is motivated by the concept.

But the logical error that is being made by the proposal is to
conclude that you are able to _infer_ one author's intent from that of
others. Since there is nothing in the HTML spec that says that
@class="copyright" means _anything_ at a global level, then even if
100 authors use it in the way that is being suggested, you *cannot*
infer from that anything about author 101.

(And that is putting aside Bjoern's perfectly correct points that the
spec doesn't actually say what @class="copyright" means anyway.)



USE CASES AND REQUIREMENTS

Don't get me wrong though--the fact that 'copyright' is an oft-used
class name is still a very useful piece of information. It tells us
that copyright information is something that authors (or at least
their publishing software) are quite prepared to add to their
documents, and so it gives us a clue that if we could come up with a
standard way of allowing this, we'd end up with some very useful
metadata to make use of.

But I seriously worry about what kind of standard will emerge when
this very useful use-case is being used not to tell us that there is a
requirement, but to tell us how to actually provide a solution to that
requirement--i.e., to justify defining that @class="copyright" now has
_global_ semantics when before it didn't.

If we were talking about @rel="copyright" that would be somewhat
different, since @rel indicates a relationship between two documents,
and authors would be consciously using a globally valid technique to
add metadata. But the definition of @class tells us only that it can
be used for semantics, and tells us anything about the values.



INFERRING MEANING

Of course, in some specific environment, it might be useful to infer
that @class="copyright" has meaning. Google, for example, could make
use of this, and show us the text in the search results, from any
element that has this class value. But in this situation, if they get
it wrong, it's not the end of the world. And more than that, they
could use other rules on their servers to process the document and the
element's content, and work out whether some element really is a
copyright message.

But 'inferring' meaning from documents in this way to aid processing
is a far cry from inferring the syntax. And this is because, as others
have said, @class cannot *by definition* be deemed to be unambiguous.



XHTML 2

It's frustrating to see the very discussions that we've had over the
years in the XHTML 2 work now happening all over again, but I guess
that is almost inevitable when politics is such a key part of
standards-making--so there's no point in complaining. :) In this
particular area we also considered tweaking things so that existing
@class values had universal meaning, but in the end we concluded that
all we could say about _existing_ @class values was that they were
'locally defined', i.e., they were private to the author. Since there
was no mechanism for an author to indicate that they had chosen some
'global' value, then it would be incorrect of us to assume that they
had.

However, that is not the case with @rel and @rev, since there are some
predefined values. And it is also not the case with @role, since that
says that non-prefixed values are reserved (to answer Geoffrey's
question). And finally, we felt it was also not the case with values
of @class that look like XML QNames, i.e., are 'qualified'; we felt
that an author using 'dc:creator' as a class value almost certainly
knew what they were writing (since it is currently not a very common
practice), and so it was legitimate to 'infer' something more from
this than some CSS styling rules.



CONCLUSIONS

So firstly, I would say that there is not necessarily anything wrong
with deriving 'universal' meaning from @class values, but we can't
unfortunately say anything about pre-existing values. Going forward,
any values that want to be part of some 'global' dictionary need to be
'qualified' in some way. This has been discussed in this thread, with
one option being to find a unique prefix. That's not a bad solution,
but as every language designer knows, no matter what you are doing,
you very quickly come up against the problem of namespacing. Our
approach was therefore to use an XML namespace style approach, with
the CURIE syntax being proposed to support this:

  <http://www.w3.org/TR/curie/>

But secondly, I would say that using @class rather than the role
attribute to carry values that are about the structure of a document,
could appear to be an example of the 'not invented here' mindset. I'm
sure it's not, but I would urge people to consider @role for this
task, since:

  * @role was created specifically to allow authors to say what an
element's purpose is;

  * it was further motivated by trying to provide an 'unpolluted'
value space so that there
     would be no ambiguities;

  * it is available as a standalone module that can be used in different mark-up
    languages;

  * it has been added to Firefox already.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Monday, 7 May 2007 13:22:20 UTC