POV-Ray : Newsgroups : povray.off-topic : The curse of Web technology Server Time
3 Sep 2024 17:19:20 EDT (-0400)
  The curse of Web technology (Message 1 to 6 of 6)  
From: Invisible
Subject: The curse of Web technology
Date: 10 Aug 2010 06:47:41
Message: <4c612e4d$1@news.povray.org>
Ah yes, that's the wondering thing about the Web, isn't it? So many 
browsers, so many incompatible implementations. The standards are 
usually incomprehensible - and it doesn't matter, because nobody 
implements them as written anyway. And the various tutorials around the 
place never, ever tell you WHAT YOU ACTUALLY WANT TO KNOW!!! >_<

Now I remember why I started avoiding this stuff in the first place.

The maddening thing is, usually the magical incantation that you need to 
utter is actually very simple. It's just that it will take you many, 
many hours to discover WTF it actually is.



My goal is simple: To be able to write content and be able to easily 
reformat it, restyle it, convert it to various file formats, and so 
forth. The way I did this previously was to design a language syntax, 
build a parser for that syntax, and write various transformation 
backends. Which, needless to say, is a fair amount of work.

And then I saw DocBook, and quite liked it. There are various XSLT 
bundles that will convert DocBook into a number of different formats. 
Still, DocBook does not precisely fit my needs either. But it's just 
XML, right? I can *make up* a markup that does fit my needs, and then 
write the necessary XSLT to turn it into... whatever.

Big mistake!

First, waste 15 minutes trying to figure out how to link an XSLT 
document to an XML document. (Mind you, I'm still just amazed that a 
*browser* can do XSLT now. When I learned this stuff, you had to pay big 
bucks for the necessary software to do it on the server-end.) I still 
have no idea how you arrange for a document with multiple possible 
transformation paths.

Next, XSLT provides a way to say "now transform all elements mathcing 
this pattern", but there is, as far as I can tell, absolutely *no way* 
to say "all elements NOT matching this pattern". Instead you must 
apparently hand-enumerate every possible element that might occur 
*except* the one you want to exclude. Yeah, that's real maintainable.

Of course, the best part is that as soon as you start using XML, you 
can't say → anymore. It just doesn't work. You have to manually 
define all those entities all over again. And this is where things 
become *excruciatingly* difficult.

I just wasted about 45 minutes banging my head against the computer 
screen trying to comprehend *why* Firefox is utterly ignoring all my 
entity definitions. I've check, double-checked and triple-checked my 
code, compared it endlessly to the example code, and it JUST DOESN'T 
WORK, for no apparent reason.

In utter desperation, I opened the file with IE. Instantly, it worked 
perfectly.

What the *hell*?! Which parallel universe have I just landed in? 
Something *works* in IE and *doesn't work* in Firefox? That's 
impossible! Nothing *ever* works in IE!! Even the IE-specific stuff 
doesn't work in IE!

Now I remember why I gave up in the first place...


Post a reply to this message

From: Le Forgeron
Subject: Re: The curse of Web technology
Date: 10 Aug 2010 08:03:38
Message: <4c61401a$1@news.povray.org>
There is even worst... Firefox will not open a xlst which is not on the
same server as the xml file (they claim security reason).

Opening a local file:// would not be the same as opening the same via
http:// (for the xml/xlst at least): file:// would not process it as xml.

-- 
A: Because it messes up the order in which people normally read text.<br/>
Q: Why is it such a bad thing?<br/>
A: Top-posting.<br/>
Q: What is the most annoying thing on usenet and in e-mail?


Post a reply to this message

From: Invisible
Subject: Re: The curse of Web technology
Date: 10 Aug 2010 08:06:41
Message: <4c6140d1$1@news.povray.org>
Le_Forgeron wrote:
> There is even worst... Firefox will not open a xlst which is not on the
> same server as the xml file (they claim security reason).
> 
> Opening a local file:// would not be the same as opening the same via
> http:// (for the xml/xlst at least): file:// would not process it as xml.

Thank Crunchy I'm only trying to do this locally...

For that matter, what I "really" want to do is take a document and 
permanently transform it. I guess I can't use a web browser to do that.


Post a reply to this message

From: Le Forgeron
Subject: Re: The curse of Web technology
Date: 10 Aug 2010 08:20:49
Message: <4c614421$1@news.povray.org>
Le 10/08/2010 14:06, Invisible a écrit :
> Le_Forgeron wrote:
>> There is even worst... Firefox will not open a xlst which is not on the
>> same server as the xml file (they claim security reason).
>>
>> Opening a local file:// would not be the same as opening the same via
>> http:// (for the xml/xlst at least): file:// would not process it as xml.
> 
> Thank Crunchy I'm only trying to do this locally...
> 
> For that matter, what I "really" want to do is take a document and
> permanently transform it. I guess I can't use a web browser to do that.

There are xslt processors which can do it.

http://xmlsoft.org/XSLT/xsltproc2.html

-- 
A: Because it messes up the order in which people normally read text.<br/>
Q: Why is it such a bad thing?<br/>
A: Top-posting.<br/>
Q: What is the most annoying thing on usenet and in e-mail?


Post a reply to this message

From: clipka
Subject: Re: The curse of Web technology
Date: 10 Aug 2010 10:29:02
Message: <4c61622e$1@news.povray.org>
Am 10.08.2010 12:47, schrieb Invisible:

> Next, XSLT provides a way to say "now transform all elements mathcing
> this pattern", but there is, as far as I can tell, absolutely *no way*
> to say "all elements NOT matching this pattern". Instead you must
> apparently hand-enumerate every possible element that might occur
> *except* the one you want to exclude. Yeah, that's real maintainable.

Try "E1 except E2", with E1 and E2 being arbitrary XPath expressions, e.g.

     * except FOO

to get everything NOT matching FOO. (Well, all tags that is; it won't 
give you the attributes, and I'm not sure anymore whether it would give 
you text elements; you'll have to see for yourself.)


For a good XSLT reference (well, at least it had helped me a lot) see 
http://www.saxonica.com/documentation/.


> I just wasted about 45 minutes banging my head against the computer
> screen trying to comprehend *why* Firefox is utterly ignoring all my
> entity definitions. I've check, double-checked and triple-checked my
> code, compared it endlessly to the example code, and it JUST DOESN'T
> WORK, for no apparent reason.
>
> In utter desperation, I opened the file with IE. Instantly, it worked
> perfectly.
>
> What the *hell*?! Which parallel universe have I just landed in?
> Something *works* in IE and *doesn't work* in Firefox? That's
> impossible! Nothing *ever* works in IE!! Even the IE-specific stuff
> doesn't work in IE!
>
> Now I remember why I gave up in the first place...

My solution to this was to not use XSL as the "final thing", but just as 
a data container that I would then "compile" into a set of XHTML pages.

Didn't get that project finished though either :-/


Post a reply to this message

From: clipka
Subject: Re: The curse of Web technology
Date: 10 Aug 2010 10:36:21
Message: <4c6163e5$1@news.povray.org>
Am 10.08.2010 14:06, schrieb Invisible:

> For that matter, what I "really" want to do is take a document and
> permanently transform it. I guess I can't use a web browser to do that.

I'd recommend Saxon-HE; it's the private-use open source version of a 
professional XSLT processor. You can choose between a Java and .NET version.


Post a reply to this message

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