Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>>  Transform to what?
> 
> 
>>POVXML(with a lot of extensions) -> POVXML(with fewer extensions) -> 
>>POVXML(with no extensions) -> POVRay SDL -> BMP
> 
> 
>   So what you want is a *separate* application which converts your
> pov-XML to SDL and then uses POV-Ray to render the image?

Exactly!

>   Then why not just go ahead and create such XML specification? Let's see
> how much people will be using it...

I can do that, sure. I'd have to spend a lot of time for that. But why 
should I do that if I would become the only user of this specification? 
If one single person (me) works on such a specification it would 
certainly have errors. I need people to correct it and just test it. So 
I thought: "Maybe it's a good idea to search for other people who are 
interested in such a thing for it might prove really useful". That is 
why I posted.
So: Is there anybody interested?

>>>  You have to still remember that the SDL is a programming language, not
>>>a document.
> 
> 
>>What's the difference?
> 
> 
>   By definition in a markup language you have to tell for each distinct
> item its type (in XML in the most cumbersome way with starting and
> ending tags). An XML parser can then do something with each type
> according to some specification of how each type should be interpreted.
> 
>   In a programming language you don't need to specify the type of
> each item which appears in the program source code. This is because
> a programming language is typically not designed so that it can be
> parsed with a generic markup parser but needs a parser specific to
> that programming language. The advantage of this is, naturally, that
> it makes it easier for the user to write programs using this language
> because it's the language parser which performs the task of tokenizing
> the input, not the user.
> 
>   If you write XML by hand you are burdened with this extra task which
> should be something the parser does.
> 
>   Besides, being a very generic markup language which does not offer
> anything specific to any programming language, most programmatical
> constructs need to be done either with extremely bloated syntax
> where you (not the parser) tell the program for each single item
> what it is, or either you use a very artificial syntax of putting
> the whole thing into a string (which you should not be required to do
> in the first place; just the fact that the quotation marks and other
> extra syntax around these strings are not part of the expression should
> immediately give you a hint that there's something unneeded there).
> 
>   In a programming language you say typically: a=b;
>   Now, just think about how you would do that same thing in XML and
> how much of that line will be additional bloat which is not really
> part of the command but is required by XML. Also think why the user
> should write that extra stuff when there's no need.
> 
>   The user and the program (in this case POV-Ray) are not interested
> in the markup of the input, they are only interested in its meaning.
> It just doesn't make any sense to force the user to specify any
> markup on the input since none is needed for anything.

I think I start to get your point. As you observed: I don't think it is 
wise to force anybody to another syntax. I just think there should be an 
alternative. POVRay SDL is ok for a wide range of tasks. But not for all.

So it's basically a trade-off between parser complexity and 
syntax-ease-of-use. But there are cases in which I want to parse a 
POVRay SDL myself, for example to do certain conversions or adaptions. 
If there was some API for that parser my problem would be (almost) 
solved. But there is none. There are still features missing in that damn 
thing and POVRay 4.0 isn't even in development yet. At least I couldn't 
find a bit of information about it except that it is supposed to be 
great and so on; nothing specific. What do you suggest to solve this 
problem? Write an own parser for POVRay SDL? Change POVRay SDL?

>>XML offers all these things in one standard that many people know of.
> 
> 
>   Can't you understand that XML is not the right tool for writing a
> program? Programs are usually written by hand, and this task should be
> made as easy as possible.

I do understand that. But POVRay SDL isn't a full featured programming 
langugage. It seems to me to be comparable to BASIC but not even to 
Pascal or gems like C++. So POVRay SDL has to move on, definately. But I 
don't see that neccessary movement yet.

>   What you are suggesting is making the life of the users harder in order
> to make the life of the programs easier.

Almost right. If you write parsers you will be glad of this.

>><sphere center="0,0,0" radius="5"/>
> 
> 
>>compare this to:
>>sphere {<0,0,0> 5}
> 
> 
>   Why should the user be burdened with all that additional syntax?
> What does it benefit the user that he is forced to write all those
> extra symbols and keywords?
> 
>   Besides, that extremely simplistic example is too naive. How would
> you write this in XML so that it makes the life easier for someone
> (for the user, or the parser, or the renderer or anyone):
> union
> { #declare IndX = 0;
>   #while(IndX < MaxX)
>     #declare IndY = 0;
>     #while(IndY < MaxY)
>       sphere
>       { <IndX*5+1, IndY*0.25-1.25, -5>, IndX*IndY/10
>         #if(IndX < MaxX/2)
>           pigment { rgb <IndX/MaxX, IndY/MaxY, 0> }
>         #end
>       }
>       #declare IndY = IndY*.125;
>     #end
>     #declare IndX = IndX*.5;
>   #end
> 
>   pigment { rgb x } finish { specular .5 roughness .03 }
> }
> 


Hm, interesting example. You might have a 1:1 translation like this:

<union>
<declare l="IndX" v="0"/>
<while cond="IndX<MaxX">
<declare l="IndY" v="0"/>
<while cond="IndY<MaxY">
and so on...
</while>
</union>

You also might also leave it to XSLT to execute your programming stuff. 
That might look like this:

<!-- MaxX and MaxY have to be known at transformation time-->
<xsl:template name="myloopinner">
<xsl:param name="IndY"/>
<xsl:param name="IndX"/>
<xsl:if test="$IndX < $MaxX"/>
<sphere center="$IndX*5+1, $IndY/4-1.25, -5" radius="$IndX*$IndY/10">
<rgbpigment value="$IndX/$MaxX, IndY/MaxY, 0"/>
</sphere>
<xsl:call-template name="myloopinner">
<xsl:with-param name="IndX" select="$IndX"/>
<xsl:with-param name="IndY" select="$IndY/8"/>
</xsl:if>
</xsl:template>

<xsl:template name="myloopouter">
<xsl:param name="IndX"/>
<xsl:if test="$IndX < $MaxX"/>
<xsl:call-template name="myloopinner">
<xsl:with-param name="IndX" select="$IndX"/>
<xsl:with-param name="IndY" select="0"/>
</xsl:call-template>
<xsl:call-template name="myloopinner">
<xsl:with-param name="IndX" select="$IndX/2"/>
</xsl:call-template>
</xsl:if>
</xsl:template>

<union>
<xsl:call-template name="myloopouter"/>
<xsl:with-param name="IndX" select="0"/>
</xsl:call-template>
<rgbpigment and so on>
</union>

This is terrible code. I do hate pure XSLT. There are, however, some 
systems that simplify the use of loops and so on. I just haven't had a 
closer look at them yet. A very promising project seems to be here: 
http://sourceforge.net/projects/xsltsl/

One other thing: I haven't tested this code. It's quite likely that it 
won't work. But I hope you see that it is at least possible. People who 
are used to work with XSLT will most likely find much cleaner and 
simpler solutions.


Besides: Your code is nonsense. 0*0.125 is always 0. Your code will 
either do nothing or never finish.

Regards,
Bernd Fuhrmann

Post a reply to this message