- From: Charles McCathieNevile <charles@w3.org>
- Date: Sun, 9 Dec 2001 22:07:36 -0500 (EST)
- To: Michael Smith <smith@xml-doc.org>
- cc: <www-amaya@w3.org>, <Jose.Kahan@inrialpes.fr>
Hi Mike, yes, XSLT might be a bit of overkill for this case, but it would be nice in geenral to have an XSLT transformation engine, and it would do this job fine. (I don't really care how the function is implemented of course). Actually tables are more than just a layout convention, they specifiy some kinds of 2-dimensional relationships between data - which is more powerful than general XML tree structure, and less powerful than full RDF graphs. It turns out that there is a lot of such data around, so it is a useful construct to have, but as you say it does mean rethinking some conventions to get the interface right. Cheers Charles On Sun, 9 Dec 2001, Michael Smith wrote: Charles McCathieNevile <charles@w3.org> writes: > language easily. Would it be possible to add an API to an XSLT processor, > and write the transformation as an XSLT (this would be a good thing to do in > general)? Hm, using XSLT to handle it kinda seems like it might be overkill to me. I have not idea how the similar functionality is handled in other apps, but I'm sure it's not with XSLT. ... Yeah, tables are always sort of an exception. Even in a DTD like DocBook that by design does not include any other presentational markup, you've got to have markup for tables, which is really just saying how the content should be presented/formatted/arranged visually-- in an paricular arrangement of an explicit number of columns and rows and spans, which can't vary no matter what output format (PDF, HTML, whatever) the content ends up being delivered in.
Received on Sunday, 9 December 2001 22:07:39 UTC