[uf-discuss] “Premature optimization is the root of all evil (or at least most of it) in programming.” — Donald Knuth

[Brian Suda]

Since there have been some discussion that have spanned over several
different thread and references to cross-over thread posts, i thought
i might try to collapse some of it and try and make it slightly less
situation specific.

There have been discussion on both the currency threads, the weights
and measures threads and the size/bandwidth threads which are
concerned with "bloat". (my other problem is Gmail's conversations are
great, but i tend to read a whole thread, and these cross-posts
sometime are before or after other answers in different threads - so
pulling them together should help prevent redundancy in answers - i
hope.)

I'll try and pull out a few of the points from the different threads,
if you don't see your favourite let me know.

There seems to be some worry about newbies having to remember some
more complex structure

<... class="container">
   <... class="type"></...>
   <... class="value"></...>
   <... class="units"></...>
   ...
</...>

I would first like to point out the quote, that "Premature
optimization is the root of all evil", i'm not saying that we should
NEVER optimize, but i think as we are developing the microformat, we
should be as explicit as possible, we can always RELAX the rules
later, it will be impossible to impose new ones if problems emerge. So
my vote, is to stick with the more verbose and start marking things up
(we don't even have consensus on a format yet). Then after it has been
in use, and we can show how great it is, then we can start taking away
blocks and creating optimizations, then check to make sure nothing
falls apart, wash, rinse, repeat....

In another thread there as discussion on another optimization idea.

Declare some sort of 'default', so you can say 'all TELs, with no type
are to be considered TYPE=work' or something along those lines. In
itself, i have no problems with this, i do have a few reservations

1) some of this is the job of the spec
2) the next quick follow-up is always, but in these X situations, i
don't want it to apply and that adds more complexity - remember we are
NOT trying to solve all the worlds problems, microformats are a
light-weight solution - they MIGHT NOT be for your problem and that's
OK.
3) Are there any sort of ALREADY existing elements' semantics that we
can use? (for example if there is a default element, like <base> for
uris)

One of the example pages given was:
http://www.oxfordjournals.org/access_purchase/2007/institution_price_list.html
It is a pretty heavy table of books and prices in 3 different
currencies. There are several semantic attributes that already exist
in HTML Tables (we should do a better job evangelizing them) which
allow for "defaults" for columns and rows (and/or arbitrary
call-backs)

There is some documentation here:
http://microformats.org/wiki/hcalendar-brainstorming#hCalendar_authoring_best_practices

I can't seems to find more info on the wiki (some one else might know
more???) but a quick search in the archives has a thread from FEB
about this:
http://microformats.org/discuss/mail/microformats-discuss/2006-February/003045.html

not many people are asking for TABLE support these days. :)

I'm open to any thoughts, examples, rebuttals, on some of these
topics, or if you have more you want to discuss, this would be a good
place to do so.

-brian

-- 
brian suda
http://suda.co.uk