>> 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

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

>>> 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

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

On 21/02/2012 17:14, Warp wrote:
> 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?

No, I wanted to put that information into a separate file, that's all. 
It's not a complex idea.

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 21/02/2012 17:14, Warp wrote:
> > 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?

> No, I wanted to put that information into a separate file, that's all. 
> It's not a complex idea.

  Create an xml file that includes (using XInclude) the other XML file
you want as well as the xsl file?

-- 
                                                          - Warp

Post a reply to this message

Am 21.02.2012 11:09, schrieb Invisible:

>> 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.

That's why they warn about this possible difference, so that the user 
can decide whether to (a) make sure that the XSLT file is only used with 
an XSLT processor that supports the feature, or (b) make sure that the 
output is not *completely* incorrect if the feature is unavailable.

That's not broken spec, that's just perfectly normal optional features.

> 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...

Ah, so your /real/ problem is a crappy text editor.

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

Because they're a HTML-specific invention?

Post a reply to this message

On 21/02/2012 08:40 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> On 21/02/2012 17:14, Warp wrote:
>>> 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?
>
>> No, I wanted to put that information into a separate file, that's all.
>> It's not a complex idea.
>
>    Create an xml file that includes (using XInclude) the other XML file
> you want as well as the xsl file?

That's a great idea. Except that apparently no browser supports XInclude 
yet. As I pointed out in my original post.

Post a reply to this message

>> 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.
>
> That's why they warn about this possible difference, so that the user
> can decide whether to (a) make sure that the XSLT file is only used with
> an XSLT processor that supports the feature, or (b) make sure that the
> output is not *completely* incorrect if the feature is unavailable.
>
> That's not broken spec, that's just perfectly normal optional features.

It's a broken spec, in that it provides no way to design a transform so 
that if DEO is not implemented, the output still looks sane. There isn't 
even a way to say "sorry, the required feature is not available". 
Instead, it just prints random gibberish without telling you or giving 
you any chance to correct it.

>> 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...
>
> Ah, so your /real/ problem is a crappy text editor.

The /real/ problem is that there is no way of knowing what encoding a 
given text file has. So it's not safe to use non-ASCII characters in a 
text file. Which is why character entities were invented in the first 
place...

>> (Let's not even get into the question of why the standard character
>> names /only/ work in HTML, and not all SGML file types...)
>
> Because they're a HTML-specific invention?

Um, why?

It's not like only HTML could possibly need non-ASCII characters.

Post a reply to this message

Am 22.02.2012 10:07, schrieb Invisible:

>>> 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...
>>
>> Ah, so your /real/ problem is a crappy text editor.
>
> The /real/ problem is that there is no way of knowing what encoding a
> given text file has. So it's not safe to use non-ASCII characters in a
> text file. Which is why character entities were invented in the first
> place...

Use an editor that places a BOM at the start of UFT-8 files and bob's 
your uncle.

Post a reply to this message