[microformats-discuss] XHTML tables as CSV-like "records"?

Dr. Ernie Prabhakar drernie at opendarwin.org
Sun Oct 2 21:17:38 PDT 2005

Hi Tantek et al,

On Oct 2, 2005, at 1:30 PM, Tantek Çelik wrote:
> Right.  Before jumping to a microformat, we should always first  
> ask, can I
> "just" use XHTML elements to do this?  And if not, can I create a  
> simple
> XHTML compound to do this?

I'm not sure I understand the distinction being made (I'm still  
trying to figure out the terminology, I guess).   I appreciated all  
the comments, but the most relevant for me was Kevin's:

On Oct 2, 2005, at 12:00 PM, Kevin Marks wrote:
> This is something we discussed last year in 'Can your website be  
> your API?',
> http://tantek.com/presentations/20040928sdforumws/semantic-xhtml.html
> I think it is worth writing out a set of rules, as we did for XOXO.  
> In particular, XOXO constrains each <dt> to one <dd> for  
> simplicitly of dictionary mapping, and constraining to have a  
> uniform grid of rows and columns makes sense.
> You can represent n=dimensional arrays in XOXO as nested lists, but  
> a 2d table is a very useful special case.

That is precisely my point.  I want to know:

a) How -best- to use *existing* XHTML table markup to indicate that  
idea of a nested list (or list of dictionaries)

As (I think) Ryan said:

On Oct 2, 2005, at 11:33 AM, Ryan King wrote:
> the talk also discusses some of
> the lesser know attributes already build into tables, such as AXIS,
> HEADER, COLGROUP, ROWGROUP, ID, etc[1]. Even some of the regular
> elements, TBODY, TH, etc. These already have some semantic meaning, so
> a new microformat might not be needed for this application

Yes, I'm pretty sure we don't need new markup *inside* the table --  
the existing semantics should work fine.  However, I *do* think we  
need conventions about *which* semantic elements to use, and how to  
interpret them.  For example, should "scope" always be explicitly  
specified?   Should we expect *all* conforming tables to have a  
header row (using <th>)?  Or, how do the semantics change if a given  
element is or is not present (e.g., does it become a 'tuple' instead  
of a 'dictionary' if there's no headers?).

Which brings me to my second point

b) What differentiates a microformat from a design pattern from an  
HTML compound?

Is it just the presence of a class name?   In this case -- as at  
least Kevin seems to agree, even if nobody else does -- doesn't it  
make as much sense to have a unique classname for structured tables,  
analogous to "xoxo" for lists? To show that the conventions *are*  
being followed?

Or is there some subtlety here I'm missing?

Conversely, could we conceivable add 'table' as an element of XOXO  
(explicitly defined as a 'compact' representation of multiple lists)?

I'm not trying to 'hurry' into anything -- I'm genuinely confused,  
and open to any and all suggestions. :-)

- Ernie P. 

More information about the microformats-discuss mailing list