Re: Literal Text

[Andrew McNaughton <andrew@xxxxxxxxxxx>]

I thought about this one for quite a while.  Of course there is a reason why 
XSL should be able to produce ill-formed output - it's useful to do so.  The  
question is what balancing reasons exist as to why it should not perform this 
task.

Unlike the situation with CSS, I don't think that this facility would make XSL 
significantly more complicated to use for other tasks.  As XSL stands, it can 
as easily be used to build an object tree as a text stream as output, and 
losing that feature would be a substantial drawback.

In the context of producing text output, which is how I've been seeing XSL, I 
think a literal-text output facility would vastly extend the range of what XSL 
could be used for, at very little cost in terms of complicating use for other 
purposes.  Not having such facility is a substantial loss.  Relegating this 
function to other languages means people would have to learn yet another 
syntax - unless it was decided that this new language should look like XSL 
with a couple of extra features.

If an XSL stylesheet returns an object tree branch which could be rendered as 
text like this:

<xsl:literal-text>&amp;perl-proc();</xsl:literal-text>

That is still well-formed.  If the rendition of that object tree to a textual 
representation was defined as producing:

&perl-proc();

then that has implications for how the XSL stylesheet should be rendered, 
being that it is itself an XML document containing the <xsl:literal> element.


My current thinking is that a <xsl:literal-text> feature would have to be 
regarded as post-processing of the constructed object-tree, but that there is 
a good deal of sense in standardising a notation.  There seems to be some 
problems which cannot be solved with XSL, but that can be solved by applying 
an XSL transformation to the result of another.  Perhaps we need a way of 
specifying a chain of stylesheets to be applied in order, some of which might 
be XSL, and another might be a filter which expands the content of the 
literal-text element (which would then not belong in the xsl namespace).

Andrew McNaughton







> Hi.
> 
> I agree with you wholeheartedly, and sincerely hope that we get the tools
> you describe. However XSL isn't one of those tools, and there is no reason
> why it should be any more than CSS should be.
> 
> Cheers
>      Guy.
> 
> 
> 
> 
> 
> xsl-list@xxxxxxxxxxxxxxxx on 03/27/99 10:52:58 AM
> 
> To:   xsl-list@xxxxxxxxxxxxxxxx
> cc:    (bcc: Guy Murphy/UK/MAID)
> Subject:  Re: Literal Text
> 
> 
> 
> 
> 
> [SNIP]
> 
> While it's good to have a tool for transforming XML->XML, and I see some
> advantages to having a tool that catches you when you fail to produce well
> formed XML, I really think that there should be a way to produce other text
> formats when appropriate.
> XML is designed as much as anything for easy interchange of data.
> Otherwise we
> might as well go back to binary formats.  Given that, what's the use of an
> interchange format without good tools for converting to and from other
> formats.
> Why shouldn't XSL have an <xsl:decode-text> mechanism that expands entities
> and
> removes the markup surrounding CDATA sections without regard for
> well-formedness?  Appropriate naming should mean that anyone using it will
> know
> that they don't get any guar!
>  antee of well-formedness in their output.
> Andrew McNaughton
> 
> 
> 
> 
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 

-- 
-----------
Andrew McNaughton
andrew@xxxxxxxxxxx
http://www.newsroom.co.nz/



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list