W3C home > Mailing lists > Public > www-tag@w3.org > July 2007

Re: microformats, profiles, and taking back rel/class names [standardizedFieldValues-51]

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Sun, 22 Jul 2007 21:54:00 +0100
Message-ID: <640dd5060707221354u18f9838fqbc0d9c83b6f95421@mail.gmail.com>
To: "Dan Connolly" <connolly@w3.org>
Cc: www-tag <www-tag@w3.org>

Hi Dan,

> Originally, values of @rel and @class were the author's choice,
> much like HTTP path names. In both cases, well-known names
> have cropped up. rel="tag" and class="vcard" are much like /robots.txt

@rel/@rev are different to @class.

With @rel/@rev, the HTML specification lists a few clearly defined
values, and then states that an author choosing to add others should
use @profile. @class doesn't make any mention of predefined values,
and doesn't say anything about how an author may disambiguate any of
the values they choose.


> I suppose the HTML WG has the right to "take back" @rel
> and @class values, but I'm uneasy about it.

Given the above, spec authors could legitimately make a case for
adding to the list of reserved values for @rel/@rev, since authors
were 'advised' that they should use @profile if they strayed from the
list of values in the spec. For example, if you wanted to define
@rel="profile" (to jump forwards in this thread), it would be fair to
do so, since it shouldn't occur in a document with no @profile set.
Backwards-compatibility is therefore preserved.

(XHTML 2 does exactly this, defining link[@rel="profile"] to be
directly equivalent to using a profile attribute.)

Where you are certainly right to feel uneasy would be in relation to
@class. Unfortunately, there is not such a strong case for being able
to 'take back' @class values, since there was nothing in older
specifications that 'warned' authors to avoid certain values; there
certainly was nothing to say that they had to use @profile with their
@class values.


> I still think URI-based extensibility mechanisms are useful,
> but I don't have much of an argument to back my intuitions.
>   http://www.w3.org/2007/05/14-html-wg-irc#T19-47-16

I agree, and indeed we came to the same conclusion about 5 years ago,
in our work in XHTML 2. That's why the @role attribute (also referred
to forward in this thread) has been specifically designed to yield a
URI, and RDFa is geared towards allowing RDF to be embedded in HTML
and XHTML.

Since both the @role specification and RDFa are small specs that
relate to a handful of attributes, it shouldn't take much for them to
be incorporated into HTML 5, which would then have the positive effect
of keeping the W3C's 'metadata story' (in relation to HTML and XHTML)
coherent.

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 Sunday, 22 July 2007 20:54:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:46 GMT