Nigel Stewart wrote in message <38D5606D.FEF25671@nigels.com>...
>
>> Multiple languages for each platform would be very difficult to support.
>
>All you have to support is an API.
>
>--



If want you want is a graceful mechanism for supporting extensions to the
scene language, I wouldn't look much further than XML
and namespace support.

Thus, extensions to the pov scene language can be handled with namespaces.
Those authors who are interested in making scenes run on a platform which
does not support that extension should markup more carefully than those who
don't.  As long as the reference "compile" of POV gracefully handled these
extensions, what reason would someone have to object?

e.g.
<sphere class="SnookerBall">
    <megapov0_9:phat_photon>...
    </megapov0_9:phat_photo>
</sphere>

Help me out here:
Pros:
o) POV sources (like MORAY, my perl scripts, etc. as opposed to sinks, like
the raytracer itself) can markup 3D scenes with minimum fuss
o) New POV editors could exploit XML Schemas
o) The concepts of "style" are equally applicable to pov source files as
they are to XHTML
o) Source format becomes "future proof"
o) Future developers will understand XML processors in the same way that
current developers understand "i++" in C.
o) Existing, proven, technology
o) Easy way to both add new tags and incorporate third-party developer's
experiments and fun stuff
o) ...?

Cons:
o) legacy .pov files.  (see below)
o) Complexity for non-programmer user... (less of an issue for me: I think
POVML would be easier to markup than the current POV scene language, but
that's a pretty emotional statement)
o) All the newsgroup space and arguments that go into choosing what the
actual elements should be (eg. verbose like above, or concise, like SVG,e.g.
<pov:sphere transform="t[ranslate] 125*z r[otate] 0 1 0 60 s[cale] 10"...>)
[again, less of an issue, because,like most people on this list,  I love
constructive discussion)
o) Potential for "tower of babel" diversity among extensions.
o) I haven't thought about what impact this would have on the reference
implementation codebase
o) ...?

Issues:
o) I recommend staying away from DTDs if you want to use namespaces.
o) I suggest that all existing scene graph language files be supported, and
that a future version of POV has a builtin (commandline?) function to
transform from .povml  to .pov and viceversa.
o) Is there an "ANSI C"-ified  interface to XML parsing?  Code reuse would
be a good thing...
o) I'd also probably argue (hmmm, I obviously feel really feel strongly

might not scale well.  A persistant DOM engine would solve that problem, but
I don't think there is a stable code base for that sort of thing at the
moment.
o) ...?

Let's look ahead to version 5, 6, 7 of POV.  These issues should only have
to be dealt with once.


Nick Drew
hyp### [at] btinternetcom

"I'm not giving in to mob rule, I'm merely jumping on a bandwagon..."

Post a reply to this message