[microformats-discuss] RFC: Thoughts on Video and Audio Microformats

[Tantek Ç elik]

On 10/18/05 11:15 AM, "Dr. Ernie Prabhakar" <drernie at opendarwin.org> wrote:

> Hi Charles,
> 
> On Oct 18, 2005, at 11:07 AM, Charles Iliya Krempeaux wrote:
>>> To build on this a little, the "class" and "title" attributes do not
>>> imply semantics or meaning any more than any other string of
>>> characters
>>> does.
>> 
>> I don't think that is completely correct.  I think the "rel" and "rev"
>> attributes imply more semantics than "class" and "title" do.
>> 
>> Usage of "class" and "title" COULD imply semantics.  But usage of
>> "rel" and "rev" MUST imply semantics.
> 
> Yeah, that's probably fair, though at some level its a matter of
> degree, not kind.

Yes, Charles, you are correct.  In fact, 'class' by default implies no
semantics at all.  It is our use profiles to define the class names which
gives them semantics.  This may be one of the (few) innovations of
microformats, and even there, we simply resurrected a documented piece of
HTML4 which was lost (for no reason other than editorial error as far as my
research of W3C archives has been able to determine).


>> Just out of curiosity, what about non-English languages?  Every one of
>> the words used seems to be English-based.
> 
> Yes, that's true, but so is HTML .   Programming requires a fixed
> vocabulary; the goal is to ensure that user-visible data can always
> be in any language.  Anything else, frankly, is impossible to manage.

Certainly what Ernie said is true.

However, that's the not the primary reason.

The primary reason is that this began with new values for the rel attribute
(see XFN[1]).  All the current values for the rel attribute in HTML4 are in
English. In fact, so are the defined values for all attributes, the
attribute names, and the element names as well.  Thus microformats are
simply following the convention set down by HTML, following the principle of
minimal invention.

Second, the choice of names also comes from existing standards, e.g. vCard,
iCalendar.


>>> As mentioned in my previous message, "urn" will not work unless
>>> you're
>>> willing to sacrifice XHTML/HTML 4.01 compliance.
>> 
>> Yes, I agree.  (I should have confirmed that the "urn" attribute was
>> still available for the HTML anchor element, by looking at the actual
>> specification.)
> 
> To be fair: Tantek pulled a similar trick with the 'compact' element
> in XOXO, so its not entirely without precedent. :-)

Quite different actually.

The 'compact' *attribute* is in HTML4, and in the XHTML 1.1 legacy module,
thus you can actually validate using the HTML4/XHTML1.0 transitional DTDs.

Thanks,

Tantek

[1] http://gmpg.org/xfn/