[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: Venting

---

---

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

---