Elliotte wrote: > Somebody has to do it. The fact is there are some > technologies that are > going to be used both on the Web and off. Millions of people > are thoroughly > inconvenienced by their inability to use the same tools they > use for their > traditional work on the Web. Why can't Illustrator files be > posted on the > Web? Why can't Microsoft Word files be posted? The answer > really boils down > to problems with incompatible file formats. XML can solve > that problem, but > it won't if we operate under the mistaken assumption that the > Web is All > and All is the Web. But XML is already being used to solve these problems of compatibility. These issues are not really related to the one that many are objecting to. I think what is being raised by others is why formatting gets some special place: if you can use XSL to convert XML data into an XML document suitable for output to the web (say in HTML), you can also use it to convert to all sorts of other outputs, say for print. I think, therefore, that what people are objecting to is the production of a complete set of tags that are irrelevant to the non-print world. No-one who is not interested in maths has to learn MathML to get any work done, so why should they then have to learn about marginalia in order to just display a red underlined title on a web page? Myself, I'm in two minds about this. I instinctively balk at the idea of bringing formatting into the transform layer because I know I *could* solve the problem as posed by having two or more stylesheets - one for web, one for Web TV, one for Windows CE, one for SMS phones, etc., etc. I therefore have some sympathy with the view I've outlined. On the other hand, there is an interesting advantage to introducing an intermediary FO layer. If I was to change the 'general' output of my page to, for example, have an italicised title, this wouldn't affect my SMS stylesheet, but it *would* affect my web, Windows CE, Web TV and print ones. With FO, I would just change the transformation from XML to FO, and leave all the others intact, whereas with the current method I would have to change each stylesheet. This means all I'd have to write would be one stylesheet for each device, which would convert from FO to whatever that device needs (and I suppose eventually they'll understand it directly), and then from then on just change the XML->FO transform. We therefore get: OLD MODEL /---> SMS phone | | /-> Web TV | | one XML document -----> web document | | | \-> Windows CE | \---> Print NEW MODEL /---> SMS phone | | /-> Web TV | | one XML document -> format document -----> web document | | | \-> Windows CE | \---> Print As you can see, for each device you use XSL to specifically define how to transform the generalised FO elements, but once done you would rarely touch them again. All you need to do is play with the stylesheet that converts the input XML to the format layer. Which means that Elliotte's follow-up email is (sort of) wrong: > I shouldn't have to learn a > different style or mark-up language for every medium I write for. Unfortunately you probably would, but what you would do is create the second set of stylesheets as rules acting on FOs, rather than objects: how do I render italics on this device, how do I render an underline on this device, and, of course, how do I render footnotes and marginalia. Having said that, this will probably become the responsibility of the device manufacturers - in the same way that graphics card people produce drivers for their hardware, such that all we have to do is say 'draw a circle' in our programs, regardless of the device being drawn on. This creates a very big problem though; if in the middle segment I described above you want to be able to format for any conceivable device then you obviously have to address print. This means that the list of possible elements that will be available in the middle is going to be very large, and largely irrelevant to many web people, but it HAS to be in there. If it's not, then either you have to accept that you will not be able to address all possible devices with the middle layer, or you have to encode the more print type things by hand, and the web model is not very cute for this! Try thinking how you would code up footnotes, for example (proper footnotes that start in the same viewing space as the text to which they are attached, not the web version, which are usually endnotes). Now ... whether all of that should appear under 'XSL' is *not* what I'm addressing :), so don't even bother to comment on that! I'm still undecided as to whether everything I have just described could be achieved through just another transformation, using some 'FormatML' just like the mathematicians use MathML, or whether format really is 'special'. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 e: Mark.Birbeck@xxxxxxxxxxxxx XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format