In article <Xns94B1A5863FF0DZenZenPsychocom@203.29.75.35>,
 Breton Slivka <Zen### [at] ZenPsychocom> wrote:

> So, I know that there's been much talk about using XML for povray scene 
> description language, and a lot of sunk in povray purists will have none 
> of it!

It isn't purism, it's pragmatism...try to imagine what it would be like 
to code scenes in XML. Or to read scenes coded in XML. It's a terrible 
language for human editing, and not a very good one for machines.


> Suppose a standard XML syntax were established that implemented most or 
> all of the features of povray SDL, with correct nesting and such and all 
> that, with its own DTD and everything. 

Okay...now you have a much less readable, much longer form of the same 
scene. Now what?


> The DTD for the XML syntax could be used to create a binary version of 
> the povray language. That is, each opening and closing tag could be 
> assigned its own byte, or word, and be assembled into sort of a binary 
> shorthand of the XML syntax. 

You could just as well create a binary version of the script itself. Or 
better, create a binary scene format...a straight binary representation 
of a script would still be wasteful of space.


> This by itself brings the advantage of smaller filesizes for huge 
> datasets like meshes, and such, which at this point uses huge amounts of 
> data, uneccesarily by storing vector and context information as ascii 
> characters. 

I agree that a binary format would be useful for things like large 
models. XML is hardly a space-saver, though, and is not needed as an 
intermediate step between POV script and a binary file.


> This would also bring the advantages that XML brings, of easy 
> portability, parsing, and flexibility of presentation, eliminating the 
> difficulties involved in creating alternative rendering engines for quick 
> preview of povray scenes. 

But it doesn't do that. Another rendering engine will still need to know 
what data is there, and it can't do anything with data that isn't there. 
XML doesn't fix this. You end up with another subsystem in POV Ray that 
doesn't really do anything but take up developer time and confuse users.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message