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

ingo wrote:
> 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'.

Exactly. You got my point. I want to do more with my scenes.

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

Depends on what you see as solution. It's might be possible to parse 
POVRay SDL with XSLT. But it's slow and a lot of work. As long as there 
are no other solutions XML might be the best of many bad ones.

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

With the right help this is possible. Are you interested in anything 
like this? Write me an email.

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

Is (L)GPL ok?

Regards,
Bernd Fuhrmann

Post a reply to this message

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

>> 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.
>
> Is (L)GPL ok?

No, only a BSD license would be OK to facilitate use of a format in
commercial applications and allow them to make changes to the code (not the
format, but that cannot be prevented by either license).

    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:
  > No, only a BSD license would be OK to facilitate use of a format in
> commercial applications and allow them to make changes to the code (not the
> format, but that cannot be prevented by either license).

BSD? Agreed. Interested?

Regards,
Bernd Fuhrmann

Post a reply to this message