Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>>  Because there already is a language which is ten times easier to
>>>write and understand.
> 
> 
>>But not to transform. Automatic code generation is an important goal. At 
>>least I want to achieve it.
> 
> 
>   Transform to what?

POVXML(with a lot of extensions) -> POVXML(with fewer extensions) -> 
POVXML(with no extensions) -> POVRay SDL -> BMP
> 
>   You have to still remember that the SDL is a programming language, not
> a document.

What's the difference?

>>>>It would be possible to write material libraries, object libraries and 
>>>>so on without clobbering the global namespace.
>>>
>>>  If this is the problem, why is XML the solution?
> 
> 
>>Because XML supports namespaces via xmlns.
> 
> 
>   So what you are basically saying there is that XML is the only
> language in the world which supports namespaces?
>   Let me rephrase the question: If namespaces are the problem, why XML
> is the right solution compared to all other languages (including possible
> specific languages which can be created for POV-Ray) supporting namespaces?
> 
>   C++ supports namespaces as well. Why would XML be any better than C++?

C++ is VERY capable of using namespaces (and it totally rocks). I use 
them everytime. C++ namespaces in POVRays SDL would be cool. They would, 
if used properly, add a lot usability to POVRay. But how are you going 
to do them without changing POVRay itself?

>>How can you 
>>know that the names you use for variables won't ever be used by POVRay 
>>itself? Your scenes might not render in POVRay 5.
> 
> 
>   Why is XML the right solution to this? Why is it better than just
> developing a standard convention (eg. that reserved keywords will
> always be lowercase, meaning that any variable written with at least
> one uppercase letter will never conflict with a keyword)?

XML offers all these things in one standard that many people know of. Of 
course you might also develop some standard conventions, but: Hell, am I 
the first one who preaches people to develop and use such conventions? 
Where are those people? Why isn`t it in the POVRays manual on the first 
page then? If you think this is the way to go then let's go that way! 
Let's develop such a naming scheme. It's about time!

You can on the other hand use a standart that is already there, like XML 
instead of developing a new one.

>>>  And XML is the best solution for this because...?
> 
> 
>>It isn't. XML is a general markup language made by humans and has 
>>certainly it's flaws. But XML is the best general markup language I know 
>>of.
> 
>   But that's exactly the problem: POV-Ray scenes are not documents. They
> are programs. XML is a markup language, not a programming language.
> People want to write, understand and execute SDL scripts, seldom print
> them nicely. It just doesn't make any sense to write a program in a
> markup language.

XML can also be used for programming languages. It is a _general_ markup 
language. It's not limited to documents. Just look at XSLT.

>>>  And how on earth does XML make this any easier? Does XML have some
>>>magic which will allow you to tesselate any given surface?
> 
> 
>>Not really. You'd have to code it all yourself. But this is still 
>>possible. I guess it will take 1/2 year. But the point is: You cannot do 
>>this at all with POVRay since you cannot access scene objects. XSLT 
>>could do this.
> 
> 
>   In fact, you can (there have been simple tesselation SDL macros out there
> which you can give objects to tesselate).
> 
>   However, that's besides the point. If accessibility of data is the
> problem, why would XML be a better solution than a true programming
> language with the required features? Why change a programming language
> to a markup language just to get data out of elements?

Because there is already a general transformation language that can 
access any XML document. It's called XSLT. So why invent the wheel twice?

>   In a programming language you typically write things like:
> 
> (x+y^2)/(k+1)
> 
>   In XML you write that like:
> 
> <mrow>
>   <mfrac>
>     <mrow>
>       <mi>x</mi>
>       <mo>+</mo>
>       <msup>
>         <mi>y</mi>
>         <mn>2</mn>
>       </msup>
>     </mrow>
>     <mrow>
>       <mi>k</mi>
>       <mo>+</mo>
>       <mn>1</mn>
>     </mrow>
>   </mfrac>
> </mrow>
> 

Bad example. No, I'm not suggesting to do something like this:

<sphere>
	<center>
		<vector>
			<x>0</x>
			<y>0</y>
			<z>0</z>
		</vector>
	</center>
	<radius>5</radius>
</sphere>

but rather this:
<sphere center="0,0,0" radius="5"/>

compare this to:
sphere {<0,0,0> 5}

The structure doubles the size. This is still feasable. You spend more 
that much time typing sphere anyway. Most time will be spent thinking 
and rendering. So: Why not using XML instead of developing all kinds of 
naming schemes, another document object model and so on?

Regards,
Bernd Fuhrmann

Post a reply to this message