[uf-discuss] hAtom draft - class="title"

[Tantek Ç elik]

On 12/31/05 1:58 AM, "Benjamin Carlyle" <benjamincarlyle at optusnet.com.au>
wrote:

> Ryan,
> 
> On Thu, 2005-12-29 at 23:47 -0600, Ryan King wrote:
>> ...I believe that context and specific rules on opacity are
>> sufficient for making thing unambiguous. Admittedly, with
>> microformats we tend to walk a fine line here, but its not without
>> reason- we're trying to optimize for publishers- which mainly
>> includes geeks who hand-write html in textareas and web developers/
>> designers.
> 
> Is it your position that hAtom's title class can have a different
> meaning to hCard's title, and that hAtom's summary class can have a
> different meaning to hReview's summary class? Is it your position that
> opacity will allow for classes to have different definitions depending
> on scope?
> 
> Tantek, is this your position also?

No.  Like I said[1], this is one of the two most common mistakes that
namespaces both enable and encourage.

[1]
<http://microformats.org/discuss/mail/microformats-discuss/2005-December/002
498.html>

1. The same term is used to mean two different things
2. Two terms are used to mean the same things

The current "established" microformats have avoided this problem by
essentially reusing from earlier microformats when possible, *before*
reusing from other standards.

One problem with most standards committees that design a new format is that
they are typically focused only on that one format, and often pick a new
vocabular instead of acknowledging previous vocabularies and attempting
compatibility.

That's not the microformat way.  We don't invent new terms when unnecessary.
Similarly, we prefer terms from older more established standards than newer
standards.

And by the way, one of the ways to optimize for publishers is to make the
overall vocabulary of microformats easy to understand and use.  Sticking
with one term = one meaning (and vice versa) makes this much easier.

Thanks,

Tantek