POV-Ray : Newsgroups : povray.off-topic : The trouble with XSLT Server Time
27 Sep 2024 03:29:10 EDT (-0400)
  The trouble with XSLT (Message 5 to 14 of 84)  
<<< Previous 4 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Le Forgeron
Subject: Re: The trouble with XSLT
Date: 20 Feb 2012 16:10:11
Message: <4f42b6b3$1@news.povray.org>
Le 20/02/2012 18:43, Warp nous fit lire :
> (and then obviously you need a separate test.xsl file.)
> 
>   What exactly is the problem you are having?

I think I understand Invisible (ouch!):
Assume a file a.xml and another file showme_pretty.xsl

To have the browser display a.xml using showme_pretty.xsl, the a.xml
must contains the reference of showme_pretty.xsl;
There is no way to create a file a_in_pretty.xml that would
automatically combine a.xml & showme_pretty.xsl; a.xml must be copied
inside a_in_pretty.xml

Now imagine there is not ONE a.xml, but hundreds of them... Bummer!


Post a reply to this message

From: Invisible
Subject: Re: The trouble with XSLT
Date: 21 Feb 2012 04:11:31
Message: <4f435fc3$1@news.povray.org>
>> So it looks like I'm going to have to sit down and write a special tool
>> to take an XML file and copy it, inserting the correct XSL reference
>> into the header. How pathetic...
>
> That's merely a shell-script:
> 1. find the closing of the first<?xml tag
> 2. insert your xsl tokens
> 3. copy verbatim the remaining document
> 4.
> 5. Profit.

How the heck do you do that from a shell script?

...oh, wait. You probably meant a /real/ shell, not CMD.EXE, right?


Post a reply to this message

From: Invisible
Subject: Re: The trouble with XSLT
Date: 21 Feb 2012 04:16:55
Message: <4f436107$1@news.povray.org>
On 20/02/2012 05:43 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Now, it ought to be simple to write a 3-line file that says "take this
>> XML file and that XSLT file, and display the result". But after over a
>> week searching the Internet and even consulting Stack Overflow, I cannot
>> find any way of doing this. I literally cannot *believe* that something
>> so trivially simple is also so utterly impossible.
>
>    I don't understand. This in an XML file seems to work just fine (at
> least with Firefox):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-stylesheet type='text/xsl' href='test.xsl'?>
> ...
>
> (and then obviously you need a separate test.xsl file.)
>
>    What exactly is the problem you are having?

Sure, that works. But now suppose I have /more than one/ XSL file. In 
order to select which one I want applied, I have to actually edit the 
XML file.

I'd prefer to have the link between XML and XSL in a file external to 
the XML file - but apparently that is impossible. (Unless you use an 
external 3rd party XSL tool.)


Post a reply to this message

From: clipka
Subject: Re: The trouble with XSLT
Date: 21 Feb 2012 04:26:08
Message: <4f436330$1@news.povray.org>
Am 20.02.2012 17:58, schrieb Invisible:
> On 20/02/2012 04:21 PM, Invisible wrote:
>
>> (I presume it goes without saying that the first thing this code snippet
>> has to do is test whether it's running on Internet Explorer or a
>> standards compliant browser. :-P Some things never change...)
>
> Oh dear God...
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=98168
>
> Short story: Using the xsl:text disable-output-escaping='yes' setting
> doesn't work. It's supposed to allow you to output arbitrary text, and
> it works with IE, but not with Firefox. And it appears they're trying to
> claim it's IE that's broken, not Firefox. >_<

Actually both are standards compliant:

"An XSLT processor will only be able to disable output escaping if it 
controls how the result tree is output. This may not always be the case. 
For example, the result tree may be used as the source tree for another 
XSLT transformation instead of being output. An XSLT processor is not 
required to support disabling output escaping. If an xsl:value-of or 
xsl:text specifies that output escaping should be disabled and the XSLT 
processor does not support this, the XSLT processor may signal an error; 
if it does not signal an error, it must recover by not disabling output 
escaping."

IE behaves as mandated for a combo of an XSLT processor and an HTML 
rendering engine.

Firefox behaves as expected (by the spec authors) for a combo of an XSLT 
processor and a DOM tree rendering engine.

The spec concludes that "Since disabling output escaping may not work 
with all XSLT processors and can result in XML that is not well-formed, 
it should be used only when there is no alternative."


Post a reply to this message

From: clipka
Subject: Re: The trouble with XSLT
Date: 21 Feb 2012 04:36:42
Message: <4f4365aa$1@news.povray.org>
Am 20.02.2012 17:21, schrieb Invisible:
> OK, so I've written a program that generates a bunch of XML as output.
> If you open that in a web browser, it shows up as a simple parse tree.
> Which is OK, but a little verbose.
>
> Fortunately, using the wonders of XSL (specifically, XSLT) you can have
> the browser transform the raw XML into a pretty-looking XHTML document.
>
> But *only* if you edit the original XML file to mention the XSLT file
> that you want to apply.

Why does this come as such a surprise to you?

Remember that the same thing is common practice for HTML and CSS as 
well: If you want the HTML to be rendered using a particular style 
sheet, you'll usually specify that in the HTML header.

I'm not sure whether all modern browsers support client-supplied CSS, 
but I wouldn't be surprised if there were still some out there that 
don't. For instance I have no idea how to choose a custom CSS in 
Firefox; you can disable all CSS, or choose which of multiple 
server-supplied CSS to use, but that seems to be about it.


Post a reply to this message

From: Invisible
Subject: Re: The trouble with XSLT
Date: 21 Feb 2012 05:09:34
Message: <4f436d5e$1@news.povray.org>
>> Oh dear God...
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=98168
>>
>> Short story: Using the xsl:text disable-output-escaping='yes' setting
>> doesn't work. It's supposed to allow you to output arbitrary text, and
>> it works with IE, but not with Firefox. And it appears they're trying to
>> claim it's IE that's broken, not Firefox. >_<
>
> Actually both are standards compliant:

> The spec concludes that "Since disabling output escaping may not work
> with all XSLT processors and can result in XML that is not well-formed,
> it should be used only when there is no alternative."

Ah. So in fact, the W3C specification is broken, since /clearly/ a 
system should not be specified to suddenly produce completely incorrect 
output if an optional feature is not implemented.

*sigh*

Meanwhile, it looks like my only options are either to start memorising 
Unicode code points by ID, or to save my XSL file as UTF-8 and watch the 
encoding get screwed up every time I touch the file...

(Let's not even get into the question of why the standard character 
names /only/ work in HTML, and not all SGML file types...)


Post a reply to this message

From: Invisible
Subject: Re: The trouble with XSLT
Date: 21 Feb 2012 05:26:20
Message: <4f43714c@news.povray.org>
>> Fortunately, using the wonders of XSL (specifically, XSLT) you can have
>> the browser transform the raw XML into a pretty-looking XHTML document.
>>
>> But *only* if you edit the original XML file to mention the XSLT file
>> that you want to apply.
>
> Why does this come as such a surprise to you?
>
> Remember that the same thing is common practice for HTML and CSS as
> well: If you want the HTML to be rendered using a particular style
> sheet, you'll usually specify that in the HTML header.

Well, what you say is of course true.

Then again, CSS just applies a few font settings to an HTML file. XSL 
transforms one file into a totally different one. If every single time 
you open that file you're always going to apply the same transformation, 
you might as well just not bother keeping the original file, and only 
store the transformed version. It completely defeats the whole purpose 
of XSL.

Actually, no, that's not /completely/ true. If several files all use the 
same XSL, then changing that one XSL file immediately changes /all/ of 
the files that use it.

Even so, XSL is clearly crying out for the ability to apply more than 
one XSL file to the same source file. And indeed you can trivially do 
that - just not with a web browser, unfortunately.

> I'm not sure whether all modern browsers support client-supplied CSS,
> but I wouldn't be surprised if there were still some out there that
> don't. For instance I have no idea how to choose a custom CSS in
> Firefox; you can disable all CSS, or choose which of multiple
> server-supplied CSS to use, but that seems to be about it.

I only recently discovered that Firefox even has a UI for changing the 
CSS. ;-) (Or turning it off, for that matter.) I have no idea whether 
you can supply your own CSS; isn't that an optional feature of the spec? 
There's probably a way to do it, but there might not be a UI. (E.g., 
there may be something hidden in about:config somewhere.)


Post a reply to this message

From: Francois Labreque
Subject: Re: The trouble with XSLT
Date: 21 Feb 2012 08:44:05
Message: <4f439fa5$1@news.povray.org>
Le 2012-02-21 04:12, Invisible a écrit :
>>> So it looks like I'm going to have to sit down and write a special tool
>>> to take an XML file and copy it, inserting the correct XSL reference
>>> into the header. How pathetic...
>>
>> That's merely a shell-script:
>> 1. find the closing of the first<?xml tag
>> 2. insert your xsl tokens
>> 3. copy verbatim the remaining document
>> 4.
>> 5. Profit.
>
> How the heck do you do that from a shell script?
>
> ...oh, wait. You probably meant a /real/ shell, not CMD.EXE, right?

1. write the program that will do it using your favorite language 
(*cough*Haskell*cough*) and name it BAR.EXE

2. FOR %FOO in (*.xml) DO TYPE %FOO | BAR > new%FOO

Assuming BAR.EXE reads from stdin and output to stdout, this will run it 
against all the .xml files in the directory and create a second set 
called new*.xml

Alternately, find Win32 versions of awk, sed, perl, or something like that.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }


Post a reply to this message

From: Francois Labreque
Subject: Re: The trouble with XSLT
Date: 21 Feb 2012 08:58:22
Message: <4f43a2fe$1@news.povray.org>

>>> Fortunately, using the wonders of XSL (specifically, XSLT) you can have
>>> the browser transform the raw XML into a pretty-looking XHTML document.
>>>
>>> But *only* if you edit the original XML file to mention the XSLT file
>>> that you want to apply.
>>
>> Why does this come as such a surprise to you?
>>
>> Remember that the same thing is common practice for HTML and CSS as
>> well: If you want the HTML to be rendered using a particular style
>> sheet, you'll usually specify that in the HTML header.
>
> Well, what you say is of course true.
>
> Then again, CSS just applies a few font settings to an HTML file.

and positioning, and size, and background image, and whether the object 
shows up at all on a particular media, etc... but let's not let that get 
in the way of a good argument.

> XSL
> transforms one file into a totally different one. If every single time
> you open that file you're always going to apply the same transformation,
> you might as well just not bother keeping the original file, and only
> store the transformed version. It completely defeats the whole purpose
> of XSL.
>
> Actually, no, that's not /completely/ true. If several files all use the
> same XSL, then changing that one XSL file immediately changes /all/ of
> the files that use it.
>
> Even so, XSL is clearly crying out for the ability to apply more than
> one XSL file to the same source file. And indeed you can trivially do
> that - just not with a web browser, unfortunately.
>
>> I'm not sure whether all modern browsers support client-supplied CSS,
>> but I wouldn't be surprised if there were still some out there that
>> don't. For instance I have no idea how to choose a custom CSS in
>> Firefox; you can disable all CSS, or choose which of multiple
>> server-supplied CSS to use, but that seems to be about it.
>
> I only recently discovered that Firefox even has a UI for changing the
> CSS. ;-) (Or turning it off, for that matter.) I have no idea whether
> you can supply your own CSS; isn't that an optional feature of the spec?
> There's probably a way to do it, but there might not be a UI. (E.g.,
> there may be something hidden in about:config somewhere.)

You can override server-side CSS in Firefox by putting stuff in [your 
profiledir]\Chrome\userContent.css.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }


Post a reply to this message

From: Warp
Subject: Re: The trouble with XSLT
Date: 21 Feb 2012 12:14:07
Message: <4f43d0df@news.povray.org>
Invisible <voi### [at] devnull> wrote:
> Sure, that works. But now suppose I have /more than one/ XSL file. In 
> order to select which one I want applied, I have to actually edit the 
> XML file.

  What do you expect? For the XML file to read your mind?

-- 
                                                          - Warp


Post a reply to this message

<<< Previous 4 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.