Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>Why not? It isn't that difficult. People write XHTML, MathML and even 
>>SVG by hand. At least I do. So why not POVRay?
> 
>   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.

>>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.

>   The POV-Ray SDL is a *programming language*, XML is a markup language.
> Trying to create a programming language with a markup language is not
> the best possible idea.

Well. POVRay syntax won't stay the same forever, will it? Extensions 
will surely be added. There needs to be a system that assures that these 
extensions wont result in any conflicts with old scenes. 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.

>>It would become possible to access the camera settings to adjust certain 
>>values. This would make the implementation of HUD systems possible 
>>(useful if you want to mark or label certain things in your scene).
> 
> 
>   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. In fact you might ask any IT professional for the best general 
markup language and most sane will tell you: "Use XML". There is XSLT, a 
general transformation language. It is (with a few tweaks) as powerful 
as the lambda calculus and thus as powerful as POVRay itself.

>>One could even convert whole models to meshes and apply mesh 
>>modificators on them. This is AFAIK not yet possible in POVRay.
> 
>   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. Or what if you wanted an object to appear always in the 
same size. You would have to access the camera data. This cannot be 
written as an POVRay include file. You can write it easily as XSLT 
transformation from one scene to another.

>>Ok, maybe some of these things can be done in POVRay file format. But if 
>>they can be done, how clean can they be done?
> 
> 
>   It is aknowledged that the current SDL has reached its practical limits
> and that a better language may be necessary, but XML is certainly not
> the answer. POV-Ray needs a programming language, not a markup language.

Tell me: What is the fundamental difference between a programming 
language and a markup language. Both are finite. Both have a tree-like 
structure.

Regards,
Bernd Fuhrmann

Post a reply to this message

Thorsten Froehlich wrote:

> Whatever argument for XML you can give, it applies for any other format.
> The use of XML has been discussed to death before, and there are just no
> arguments for it that do not apply to the current format just as well. As
> such, there is no point to argue for XML.  To the contrary, there are things
> you can do in POV-Ray right now that would be incredibly difficult to
> express in XML.

And POVRay can do namespaces how? If it can do namespaces: Why isn't 
there anything written in the documentation? If you have to fake 
namespaces: Why isn't there a coding style guide that will advise people 
how to make extensions to existing include files and libraries?

If you haven't noticed: I'm just asking if someone is interested in 
writing such a system. Noone would be forced to switch to XML. But it 
just doesn't make any sense for me to write such a system on my own. 
Possibly other persons are interested in such a system and I'm looking 
for such persons. If you are not interested, it's ok. I don't want to 
change the default SDL. I just want to add one.

Additionaly I state that POVRay will run into big trouble (known as 
namespace clobbering) in the future. Big projects will be more difficult 
to make due to this.

Regards,
Bernd Fuhrmann

Post a reply to this message

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?

  You have to still remember that the SDL is a programming language, not
a document.

> >>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++?

> 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)?

> >   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.

> >   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?

> Tell me: What is the fundamental difference between a programming 
> language and a markup language. Both are finite. Both have a tree-like 
> structure.

  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>

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

in news:37jat050gpl1jhjhfl290afmkdbivt0f7q@4ax.com ABX wrote:

> And usually how hard it is to solve such issue?
> 

The first time it happend it took a day to figure it out, but generaly 
it's not a big problem. Still I think namespaces wouldn't be a bad thing 
to have in a future version of POV-Ray (maybe even alongside with a 
"better" way of dealing with include-file packages).


from: The Zen of Python
- Namespaces are one honking great idea -- let's do more of those!

   -- Tim Peters  ( http://www.python.org/doc/Humor.html#zen )

Ingo

Post a reply to this message

In article <41d6806b$1@news.povray.org> , Bernd Fuhrmann 
<Sil### [at] gmxde>  wrote:

> 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. In fact you might ask any IT professional for the best general
> markup language and most sane will tell you: "Use XML".

No, only the marketing department will.  Just like marketing departments
told everybody that Java is the best general programming language five years
ago.  XML is nothing but a huge hype producing documents several times the
size of a well-designed binary counterpart that can be just as "easy" to
parse (that that XML is trivial to parse).  XML certainly has its
applications, but they are limited, not universal.

Just compare the traditional VRML (POV-Ray-like) syntax version to the XML
syntax version of X3D. It will give you a very good idea why XML is
unsuitable for describing 3D data.  In fact, X3Ds XML representation is
probably one of the best examples of pointless use of XML.  Just consider
how lists of vectors are expressed in X3D XML syntax and you should really
notice.  Of course, the problem with keeping them in strings is the result
of an inherent limitation of XML expressing data only as complex, nested
collections of strings.

>  You cannot do
> this at all with POVRay since you cannot access scene objects.

That is true, you cannot do this in POV-Ray currently, but it is not a
limitation of the SDL (scene description language) but the parser design,
which is 15 years old and fairly outdated (and the 4.0 rewrite will take
care of this).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <41d68838@news.povray.org> , Bernd Fuhrmann <Sil### [at] gmxde>
wrote:

> And POVRay can do namespaces how? If it can do namespaces: Why isn't

Macros provide namespaces (#local), as do include files (#local in an
include file stays local to that file).  That there are no named namespaces
(which is what you are effectively asking for) is simply a matter of nobody
having written code for it.  It is easy to add even to the current parser.

Of course, namespaces are not an answer to naming convention problems.  You
can have the same namespace name in two files and run into the exact same
problem you created namespaces for in the first place.

The documentation advises users to not use all lower-case identifiers for
user defined declares and macros as lower-case identifiers are reserved for
use by POV-Ray.  This leaves plenty of names for users.  Prefixing has
almost the same effect as using namespaces, and looking at APIs of modern
operating systems, they do really well without need for namespaces despite
using tens of thousands of identifiers.  Of course named namespaces offer a
very valuable extension to any language, including POV-Ray SDL, not having
them is only a minor annoyance, not a huge problem.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> In article <41d6806b$1@news.povray.org> , Bernd Fuhrmann 
> <Sil### [at] gmxde>  wrote:
> 
> 
>>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. In fact you might ask any IT professional for the best general
>>markup language and most sane will tell you: "Use XML".
> 
> 
> No, only the marketing department will.  Just like marketing departments
> told everybody that Java is the best general programming language five years
> ago.  XML is nothing but a huge hype producing documents several times the
> size of a well-designed binary counterpart that can be just as "easy" to
> parse (that that XML is trivial to parse).  XML certainly has its
> applications, but they are limited, not universal.

There is a hype for XML, yes. XML is not universal, true. To give a 
simple example: XML will never be suited to save MPEG movies. It's just 
a matter of space and decoding speed. XML is not suited to contain 
executable files since they don't really interoperability. But POVRay 
files are rather small. Parsing speed does not matter that much. They 
contain highly structured data. So XML is suited to contain that data. 
XML is, however, a bit hard for newbies to write, I admit.

But who was desperately in need of some harddrive space and started to 
tweak his POVRay files? Who used shorter identifiers to save some drive 
space? Use of XML will result in files that have three or four times the 
size of normal POVRay files. So what?

Besides: There is a binary version of XML under development. If it might 
be used to contain binary data it will rock like hell, if used properly.

> Just compare the traditional VRML (POV-Ray-like) syntax version to the XML
> syntax version of X3D. It will give you a very good idea why XML is
> unsuitable for describing 3D data.  In fact, X3Ds XML representation is
> probably one of the best examples of pointless use of XML.  Just consider
> how lists of vectors are expressed in X3D XML syntax and you should really
> notice.  Of course, the problem with keeping them in strings is the result
> of an inherent limitation of XML expressing data only as complex, nested
> collections of strings.

XML is just a way to give a document (which does include programs 
aswell) structure that is easy to parse. It does not specify the 
structure itself. I'd make the structure almost equivalent to POVRay's 
structure. So there wouldn't be that much overhead to vectors, numbers 
and things. But one would have instantly have some powerful parser that 
are able to assemble scenes. You'd have to write such a parser in POVRay 
which is a hard task.

>> You cannot do
>>this at all with POVRay since you cannot access scene objects.
> 
> That is true, you cannot do this in POV-Ray currently, but it is not a
> limitation of the SDL (scene description language) but the parser design,
> which is 15 years old and fairly outdated (and the 4.0 rewrite will take
> care of this).

Interesting: So you suggest to keep the SDL while adding commands to 
access scene objects, right? But how can one access scene objects 
without some kind of object model? Example:

Assume you have some scene like this:

---
camera {location <10,20,10> look_at <0,0,0>}
light_source {<-140,200,300> rgb <1.0, 1.0, 1>*2}
sphere {<-2,0,0> 1 pigment {rgb <1,0,0>}}
sphere {<0,0,0> 1 pigment {rgb <0,1,0>}}
sphere {<2,0,0> 1 pigment {rgb <0,0,1>}}
---

So how would you write a transformation like "Replace all sphere by a 
certain mesh"? Suggest a syntax! Do you know any programming language 
what is able to access it's own objects that way?

Now for the 4.0 rewrite: What will it be like? I just googled a bit, but 
I couldn't find anything about it. How do you know that similar 
limitations like the ones described won't appear again? Is there any 
information about it available?

Regards,
Bernd Fuhrmann

Post a reply to this message

in news:41d51598@news.povray.org Bernd Fuhrmann wrote:

> What do you think about this idea?
> 

After reading most of the thread, I get the impression that you have a 
"problem" and that your "solution" to that "problem" is XML. I think I 
have a simmilar "problem", 'all one can do with a .pov file is render it 
with POV-Ray'.

I.m.o XML itself is not the solution. You gave one reason: "Obviously 
this works only in one direction". Others gave many other reasons.

What we'd need is a POV-Ray parser, and currently the only one available 
is POV-Ray and we can't use that for other purposes. I tried writing one 
in Python, but gave up due to severe lack of skills.

Once you have a POV-parser (with a liberal enough licence and with some 
API or bindings or ...) you can do many things with a scene, even 
convert it to some form of XML if you like.


Ingo

Post a reply to this message

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

Thorsten Froehlich wrote:

> Of course, namespaces are not an answer to naming convention problems.  You
> can have the same namespace name in two files and run into the exact same
> problem you created namespaces for in the first place.

Which is why I prefer the way namespaces are done in XML instead of C++. 
If you have a domain you have your own namespace. Just that simple. Any 
idea if it can be done better than that?

I know who I am. I know what I will develop. So what prefix should I 
use? This isn't in the manual.

> The documentation advises users to not use all lower-case identifiers for
> user defined declares and macros as lower-case identifiers are reserved for
> use by POV-Ray.  This leaves plenty of names for users.  Prefixing has
> almost the same effect as using namespaces, and looking at APIs of modern
> operating systems, they do really well without need for namespaces despite
> using tens of thousands of identifiers.  Of course named namespaces offer a
> very valuable extension to any language, including POV-Ray SDL, not having
> them is only a minor annoyance, not a huge problem.

Prefixes are fine, at least partially. They can add a lot of overhead. 
Namespaces would be better. But you are certainly right: It's not a huge 
problem. On the other hand: Why not doing things right as soon as possible?

Regards,
Bernd Fuhrmann

Post a reply to this message