[ANN] Kludgey workarounds for IE and Netscape

[Henry S. Thompson]

Andrew Bunner <bunner at massquantities.com> writes:

>   The moral of the story is that if your target language is not XML, then
> you have to write your own tool to take it from XML to, let's say, HTML.
> One way is to get into the XSL processor and add your own code, another
> (less clean) way is to write something that post-processes the XML
> representation of the target language.

Um, to reiterate something James said, the draft recommendation is
clear, if perhaps not as explicitly obtrusively clear as it should be,
that it specifies a process which results in an XML result tree,
representation NOT specified, not a sequence of UNICODE characters.
It also provides a rendering semantics for one family of result trees,
namely those composed of the formatting object element types and
attributes.  It nowhere states that a conformant XSL processor must be
able to output a linearised form of the result tree.  Some may choose
to.  Others may implement the rendering semantics of the formatting
objects directly, and never expose the result tree.

Nothing in the draft recommendation suggests that an application which
implements only the tree-construction component of XSL is a conformant
XSL application.  That said, it would be naive to suppose that
applications meeting this description (XT is one, of course) will not
be common.

>   Unless, of course, we change the standard.
> . . .
>   XSL seems perfectly well equipped to handle any text-based target
> language. So why not let it?
> 
>   I guess I don't see the same need to "choose something" or restrict it in
> any way other than to say "you must produce text". There must be something
> very important that we gain by insisting the target language be one thing
> or another. Help me understand what this important thing is.

As noted above, we don't WANT to require people to produce text, or
anything else except rendering according to formatting object
semantics.  XSL is a STYLE language.  It's a wonderful side benefit
that it encorporates a useful tree construction language, and of
course people will take advantage of that, but it makes sense from the
perspective of the WG's charter to use XML to describe the structure
of the result tree we need to drive the rendering process.

If you want text output, go ahead:  Define your result tree to look
like this

<wrap>
You can put any text you like in here, and it can look like
another language;

 La plume de ma tante

or ANOTHER language

 if x &lt; 3; then echo oops; exit; fi

or an other *)#)(#@) thing you like.

</wrap>

and your output procedure to strip the wrap and expand the entity
references.  You won't have a conformant application, not because you
are outputing text, but because you're not supporting the fo:
semantics.  I'm sure you'll be OK with that :-)

I hope this will clarify, wrt your very first para. above, that this
isn't an EXTRA bit of work you have to do, to "get into the XSL
processor and add your own code": ANY XSL processor which plans to
output character sequences goes beyond the draft recommendation, and
will have to include an idiosyncratic back-end.  If you know JADE,
James Clark's DSSSL engine, you will know that it has a core which
implements the standard, AND a number of backends.  A conformant XSL
implementation will probably be organised similarly: a core which
implements tree construction, one backend which renders fo:* to a
display directly using X-windows or MS foundation classes or SwingSet
or ..., perhaps another backend which renders fo:* to print using Tex
or PostScript or ..., probably a third backend which outputs the
result tree as XML, and so on.

Hope this helps

ht [speaking for myself, not the WG]
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht at cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)