Subject: Re: Literal Text From: Andrew McNaughton <andrew@xxxxxxxxxxx> Date: Mon, 29 Mar 1999 20:59:42 +1200 |
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>&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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Literal Text, Guy_Murphy | Thread | RE: Literal Text, Kay Michael |
Re: What about changing the rules?, Guy_Murphy | Date | multiple sorting modes, Linda van den Brink |
Month |