 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> 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.
>
> 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.
>
> If there /is/ a way of doing this, every single XSL tutorial in
> Christendom fails to mention it. No XSL FAQs mention it either - it's
> not even that they say it can't be done, it's that none of them even
> contain a question about this topic. This raises the alarming
> possibility that what I'm trying to do might actually be impossible
> after all. (Which is slightly daft, given that it's the entire point of
> XSL existing in the first place...)
>
> To be clear: It seems to be perfectly possible to apply any XSL to any
> XML if you use an external 3rd-party tool. You just can't do it with a
> *web browser*. You know, those programs that know about XML and XSL and
> are installed on every computer in the world. No, you have to select and
> download a special CLI utility if you want to perform such advanced
> wizardry. *sigh*
>
> My first thought: XSL lets you include one stylesheet inside another, so
> maybe you can include one source document inside... erm, no. No you can't.
>
> It looks like it /might/ be plausible to do something with the XSL
> document() function - but I haven't figured out exactly how yet.
>
> Apparently XML itself has a general include feature called XInclude.
> According to Wikipedia, "Browser support: None". *facepalm* OK, so
> that's really going to help then.
>
> About the closest thing I've found is a website that says that if you
> copy and paste a few miles of convoluted JavaScript code, you can make a
> web page that runs the script which then loads the required XML in the
> background, lots the XSL, applies one to the other, and inserts the
> result into a specific position in the DOM of the current document. In
> particular, it cannot /replace/ the current document, it can only be
> /inserted into/ it. So if your XSL generates an entire XHTML document...
> forget it.
>
> (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...)
>
> 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...
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.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/03/2012 20:56, Warp wrote:
> Nothing stops you from using&#xx; codes regardless of the encoding.
Correction: The finite limitations of the human mind stop you using hex
codes. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
> Gaah! No! Use UTF-8! 8859-1 is Western European/United States only!
Tell it to [every piece of Windows software that inspects text files].
All of these programs seem to default to that encoding, not UTF-8.
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.
>
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 09/03/2012 20:56, Warp wrote:
>
>> Nothing stops you from using&#xx; codes regardless of the encoding.
>
> Correction: The finite limitations of the human mind stop you using hex
> codes. :-P
step 1: www.google.com
step 2: "unicode chart for _____ characters"
step 3: File | print
step 4: Tape to side of computer screen.
Back when dinosaurs roamed the Earth, that's what most of us did for
DOS-based editors when we needed accented characters, or for the more
daring, ASCII graphics.
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>>
>> Gaah! No! Use UTF-8! 8859-1 is Western European/United States only!
>
> Tell it to [every piece of Windows software that inspects text files].
> All of these programs seem to default to that encoding, not UTF-8.
Change your local settings to Bulgaria or Czech Republic and it won't!
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/03/2012 01:08, Francois Labreque wrote:
>>>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>>>
>>> Gaah! No! Use UTF-8! 8859-1 is Western European/United States only!
>>
>> Tell it to [every piece of Windows software that inspects text files].
>> All of these programs seem to default to that encoding, not UTF-8.
>
> Change your local settings to Bulgaria or Czech Republic and it won't!
Won't default to UTF-8? Yes, I know. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/9/2012 2:56 PM, Warp wrote:
> Mike Raiford<no.### [at] spamme> wrote:
>>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
>> Gaah! No! Use UTF-8! 8859-1 is Western European/United States only! Any
>> characters that are not in this set will be rendered as ? or worse. UTF-8 gives
>> access to the whole of the Unicode codeset, so no data will be mangled by the
>> encoding. Sorry, I'm a big proponent of using a more universal character set,
>> especially when handling data.
>
> Nothing stops you from using&#xx; codes regardless of the encoding.
>
This is true, but, in general, UTF-8 is the better way to go, but if the
data displayed on the page comes form a different source...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/9/2012 3:38 PM, Orchid Win7 v1 wrote:
>>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>>
>> Gaah! No! Use UTF-8! 8859-1 is Western European/United States only!
>
> Tell it to [every piece of Windows software that inspects text files].
> All of these programs seem to default to that encoding, not UTF-8.
That's because nobody bothers with the encoding. But what drives me nuts
is when web-authors stick in an encoding, then use UTF-8 characters in
it. You get all sorts of ugliness.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/9/2012 3:43 PM, Orchid Win7 v1 wrote:
> 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?
Use xsl:choose and have the when statements with the appropriate test?
I'm unclear as to what constitutes a small amount of content v.s. a
large amount of content.
You could have it trigger on the string-length of the node's value, for
instance. Or, you could trigger on the number of nodes (using count)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
