POV-Ray : Newsgroups : povray.programming : A Proposal for XML POV : Re: A Proposal for XML POV Server Time
29 Jul 2024 00:28:48 EDT (-0400)
  Re: A Proposal for XML POV  
From: Charles Fusner
Date: 24 Mar 2000 19:13:20
Message: <38DC0523.BBA9B19C@enter.net>
Nigel Stewart wrote:
>         This proposal is not "anti POV script", or
>         anything like that.

Believe me, the following is not intended as an "anti-XML" speech 
either, I just feel that incorporating XML parsing into POV-Ray
directly AND maintaining backward compatibility with existing 
hand coded SDL will not meet the desired objectives, and I'm
just trying to present a reason why soas not to sound too 
irrational for saying it. After this, I'll dutifully wade to 
shore and get out of waters too deep for me <G>.

Going back to a couple of points you made...

>         3.  Support co-existance so that POV-script can
>             include XML based data and vice versa.

Ok, here's where I lose track of the plan. Because a little while
earlier, you said 

>         No, we are talking about a way that POV can be parsed
>         _without_ a special POV parser.
> 

The obvious advantage of which is that 3rd party apps wouldn't 
have to write a complete POV parser from scratch. But the 
extensibility of XML based languages comes from the founding 
princible that any code your app won't know what to do with, 
just let the parser ignore it. But while I'm impressed that
VRML is trying to evolve in this direction, I've got to wonder
how it's possible because if we do this...

>         4.  Perhaps implement special tags for backwards
>             compatibility, or supporting any version of
>             pov script.  For example:
> 
>         <povscript version="3.1">
>         // Insert your POV script here
>         </povscript>

Then what, specificly, is the XML parser going to do with the stuff
between the <povscript>...</povscript> tags? If it has no ability
to parse povscript, it has to ignore it. Yet of course it can't
parse povscript, since to incorporate the whole povscript parser
would defeat the original intent. 

But in a 3D data file, ignoring part of the scene isn't a valid 
option. Consider, for example, if you had SDL hand code that will 
programmaticly place 1500 copies of an object using a #while loop. 
Dutifully, you wrap it in <povscript> tags, and then set about 
trying to import it into a modeller that incorporates an XML 
parser. Trouble is, when the scene loads, it's missing 1500 
objects because the XML parser had no plan for interpreting the 
code in the <povscript> tags. The same is true with 3rd party
extensions to the language that were specially marked so the
parser would ignore them if it didn't recognize them.

In essence what I'm saying is: In order to model, tesselate, 
convert, run lparser mutations, do quick render previews, or 
anything else useful, the code between the <povscript> tags 
must be read and understood by the app, or the result will
be a defective import that degrades the appearace of the scene
in some way. There'd be no problem if XML-POV were a separate
entity (no pun intended) from standard POV script, but there 
are hundreds more examples like this and they all revolve 
around trying to keep POV SDL (which we both agree is a 
good thing) in XML style POV. It simply "loses too much in 
the translation."


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.