>> 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.
>
> I coded one up in C# in about 15 minutes. It doesn't take much if your language
> of choice already has a library for handling xml/xslt.

It only takes 15 /seconds/ to type in a command if you have a 3rd party 
external XSLT processor (e.g., Saxon). But apparently you can't get the 
/web browser/ to do this. You have to create a new, separate, 
transformed version of the file.

It might not sound like much, but it means every time you change the 
program that generates the XML, you can't just rerun that program. You 
have to rerun the program, and then rerun Saxon (or whatever), and then 
reload the browser page. It's a PITA.

What I ended up doing, obviously, was providing a way to change the XSL 
reference that the original program inserts into the XML file. :-P

> I found this post rather interesting as my current project is one big stylesheet
> to turn raw xml into a legible report. I've learned just how powerful the
> language is. There's a ton you can do with it, and I now wonder why everyone
> always moans and groans about how difficult it is to deal with.

[I presume you're talking about XSLT here.]

It's interesting that there's one set of facilities for processing the 
input functionally, and a separate, redundant set for processing it 
imperatively. The latter set is much less powerful to boot. (Perhaps 
that was deliberate.)

What I can't figure out is this: How do I make it process an element one 
way if it contains a "small" amount of content, and process it a 
different way if it contains a "large" amount of content?

Post a reply to this message