Cart
[Home] [By Thread] [By Date] [Recent Entries]
Abhishek,
Your line of thought is interesting, because you are treading into the midst of an area where the common XML dogma "separation of format from content" breaks down.... Peter made the classic argument for semantically-meaningful names, etc. (with which I entirely agree), but your counter example shows that the whole issue of "tabular data" is just the tip of a very large, deep iceberg, which threatens to split our ocean liner in two, half tending towards modeling our content semantically -- because we know that's a Good Idea -- robust, scalable, long-lived, versatile etc. etc. --, half towards giving up and modeling for presentation -- because a generalized semantic model proves to be very difficult, whereas just modeling a two-dimensional rows and columns is a clear way forward to our immediate goal. Why does a generalized semantic model prove to be difficult? One reason is that XML's "natural" tree structure is not capable, without enhancement, of modeling the n-dimensional matrices which often prove to underlie tabular renditions. (And yes, folks, look at printed materials of any complexity and you will not uncommonly find 3-, 4- or more-dimensional matrices presented as tables.) In view of these challenges, you might consider how the classic solution -- for example, the OASIS (CALS) table (which Peter mentions) -- goes about it. Model a conventional rows-and-columns (2-dimensional) table; annotate cells with attributes to identify their roles and semantic relations. This is kind of a split-the-difference solution, which "solves" the problem for presentation, but not necessarily or entirely for generalized processing. This is because semantic relations of critical importance to the integrity of the data set are pushed out into the attribute names and values, thereby requiring special kinds of checks, validation etc. to keep everything together. The other approach is to forget completely how something is to be presented, and simply (heh) model everything to its own proper semantics. In the domain of publishing, for which XML was (at least partly) designed for, this is often prohibitively difficult, since each table has its own semantics (prices for parts by quantities here, over there populations by region and age group, etc. etc.), and this threatens indefinite extension to the tag set. If however, you are working in a problem space where such data structures are regular and predictable, this is the preferred solution. Model it for what it is (a set of name-value pairs, an object hierarchy, whatever), and worry about how to display it later. As for the generalized n-dimensional solution, supporting querying, transposition etc. to get the tabular "views" -- that's still an interesting area for research. Cheers, Wendell I initially had a <td>, <th> kind of structure but I realized that it was locked to have a head that flowed horizontally only so I added the idea of a matrix that could flow in V or H directions and could be transposed at will. Of course in this structure if there is a "sparse" matrix (one with very few "filled" cells) then I will have to have a large number of "empty" cell holders for positioning things properly. At 10:57 AM 8/18/2003, you wrote: Peter, ====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ====================================================================== XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
