[microformats-discuss] XHTML tables as CSV-like "records"?
ryan at technorati.com
Sun Oct 2 22:45:21 PDT 2005
On Oct 2, 2005, at 9:17 PM, Dr. Ernie Prabhakar wrote:
> 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:
In short: XHTML compounds are combinations of two elements to create
a new construct with specific semantics. Nothing is added, only
recombined. For example:
Combines the semantics of <pre> with the semantics of <code> to
create a compound construct.
> 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)
Which is a very good question.
> As (I think) Ryan said:
I think it was Brian.
> 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?).
These are very good questions, for which I don't think there are any
thorough, established answers (not that people haven't addressed them
in many contexts, but we don't have a way for doing it in a lossless-
> 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?
I would break them up thusly:
microformat - an extension to xhtml, usually by adding a class, rel
or rev attributes. Some specify which elements must be used (eg,
xoxo), others don't
design pattern - good xhtml practice which emerge over time, which
are sometimes described formally
html compound - see above
> 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)?
Actually, it seems we need something like xoxo for tables:
xoxo is to outlines as ? is to tables.
> I'm not trying to 'hurry' into anything -- I'm genuinely confused,
> and open to any and all suggestions. :-)
Your questions are good and well thought out. I hope my answers have
ryan at technorati.com
More information about the microformats-discuss