[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
> 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?',
> 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. 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
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*
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