Tables are perhaps the most abused feature of HTML, with the vast majority of tables on web pages being used for layout purposes, not for presenting inherently tabular data. If (like most web designers) you are going to use HTML tables for web page layout, you cannot reflect that in the semantic XML source of a page in any way. It's only the stylesheet that needs to be concerned with layout table construction.
Sometimes, however, you may have some genuinely tabular data that you want to format into some sort of a table on a web page. Still, this does not mean that you have to think in terms of rows and columns when creating a semantic source for such a table.
If you have something you can name, do it. For example, consider a sales data table listing sales figures for several products across several years. The XML way of marking up this data would be to forget that you're working on a table and simply list all available data in an appropriately constructed element tree:
<sales-table> <product> <name>Foobar</name> <sold><year>1999</year><number>123</number></sold> <sold><year>2000</year><number>140</number></sold> <sold><year>2001</year><number>142</number></sold> </product> <product> <name>Barfoo</name> <sold><year>1998</year><number>89</number></sold> <sold><year>1999</year><number>14</number></sold> </product> </sales-table>
This approach frees you from worrying about column alignment, sort order, or empty cells - just dump all your data and you're done. All the rest will be performed automatically by the stylesheet: It can filter out a subset of the provided data, group values in rows and columns, sort them, and fill in "N/A" for missing values. Thus, the above example might come out as follows:
1998 1999 2000 2001 Barfoo 89 14 N/A N/A Foobar N/A 123 140 142
Tables from triplets. In some cases, such a data-centric approach may also make your source significantly more compact than the table rendition. Thus, a sparse table with mostly empty cells can be represented in the source by triplets consisting of a row name, a column name, and the corresponding value at their intersection. Since such a source does not contain separate lists of all columns and rows, the stylesheet will compile them from the triplets.
Is it worth it? Granted, for an occasional table or two, this may be too much work: You'll have to program your stylesheet to recognize various element types and perform various operations (such as normalizing dates) that may be necessary for your tabular data. For simple isolated tables, you may be better off more or less directly reproducing in XML the structure of the target HTML table. However, if you have a lot of simple tables (or a few complex ones) with similar data, or if your tables are updated often, the benefits of the semantic data-centric approach may easily outweigh the simplicity of the straightforward HTML imitation.
Also, the tabular data on your web site is likely to be coming from some external source, such as a database or a spreadsheet. When you write the code to update your tables automatically, it is usually much easier to first transform the external data into a semantic XML tree and then let the stylesheet do table layout.