Daren Scot Wilson wrote in message <38efe5cf@news.povray.org>...
>Thoughts on XML and POVRay...
>
>I have been away from POV-Ray for a while, busy with other things.
>So when I first saw this thread a while ago, I thought "Oh-oh, there goes
>the neighborhood!  Now what are they up to?"
>
>  I agree with computer scientists such as Don Knuth and Ian Joyner,
>who have written extensively on programming languages - one of their
>main points being that the scripts written in a well-designed language
>needs to be easy for humans to write and to read, even if it's ultimately
>destined for the machine.   Software today has so much power to parse
>very complex languages, with very complex data models, there's no
>reason to design languages to make life easy for the computer.

That's true.  We should design languages to make life easier for the
ultimate
end-user.  Who is the end-user of the POV rendering engine?  With the
current
POVscript, that's those people who want to hand-edit text files, although
there
are a group of artists who utilise modelling and animation tools which
export to
POV, and there are a group of artists who use POV as the destination of
bespoke
tools.

Let's make different languages suitable for different needs.

An additional point to the above is that choices made now impact future
developers.
While we can't predict the future, it is desirable to safeguard where
possible.  By
using a simple, extensible, parser, one can expedite the incorporation of
new ideas
with minimal fuss.   While you don't choose simplicity simply to make the
computer's
life easier, making future developers' life easier is a perfectly good
rationale.  I think
it would be wise to decide whether the current POVscript parser is suitably
robust.

>  So what if the parser is complicated?  It needs to be written only once.
>(Well, in an ideal world.)   If there comes  to be a need for several apps
>or utilities to parse the language, a parser can be written and packaged
>as a shared library or component.

This is a great minimal impact suggestion - would the terms of the license
allow such a shared library to be distributed free?  This would keep POV
a separate product, but I think it would need support from the POV team to
keep in line with changes to POV script.

Those users who wish to express POV using POVML,  POV++, etc, should
have input into the design of such a library.

>   A human-friendly language that is difficult to parse puts only a few
>programmers temporarily at an inconvenience.
>
>   An language that is easy to parse, but hard to for humans to deal with,
>puts many users at an inconvenience for a long time.

>
>
>The weakness about XML that worries me is that XML is designed to
>describe structure and meanings and properties of parts of that structures,
>not process.   That may sound good for geometric models, which are
>structures with associated properties.  But 3D scenes have patterns in
>there structures, often which can easily be described algorithmically -
that
>is,
>by "how to" descriptions, rather than "what and where" descriptions.
>
>Consider Postscript - a powerful way of describing where to put ink
>on a page.  Because it allows transformations, loops, and subroutines - and
>is in fact a general purpose programming language - it has a lot of power.
>Even at the most basic level, just about every text document involves
letters
>arranged serially left to right, and this is described easily by a process
of
>moving a "current point" according to letter  width, assumed by the
>interpreter, but one can apply commands and define subroutines to make
>very complex documents.


Postscript would obviously never be taken up as a hand-edited format, since
it has
been written with parsing simplicity in mind (a simple stack machine).
Considering
Postscript doesn't really add anything to your argument, although I take
your point
that Postscript is general programming language optimised for page layout.

One thing that you can say about PostScript is that it's a bloody pain to
work back from
a postscript document to the artist's original concepts.  If you look at the
evolution from
Postscript to PGML and then (merging with VML) to SVG, you'll see that
they've managed
to perform quite a successful balancing act between file size, readability,
extensibility, and
simplicity of implementation.

>  In contrast,  XML -- or HTML (since i am more familiar with it) merely
>says "This is a paragraph"   or "this is the radius".   It seems to me a
>"verbless"
>language, unable to say "Do this twenty times: ..."  Furthermore, it
>describes the structure of the document it is a part of - as a markup
>language, that
> exactly what it's for.  It does not describe well something else, outside
its
> own file, as the proposed notion of having an XML script describe a
>geometric model or complete scene.

I think this is a good point.  So far XML has needed an additional language
into which to escape to perform algorithmic processing - usually ECMA
script, Javascript,  or something like it.  Actually the choice of scripting
language is up to the
developer (and the target platform upon which the document will be
processed), and shouldn't
be a constraint upon the development of XML as a data modelling
language.  XML + XSLT + "AnyScript" is a pretty powerful combination.

This is a strong argument for generalising algorithmic commands out of
POVscript, allowing artists
to write loops and procedures in what ever language they wish, and requiring
the POV parser to
escape to another parser when necessary.

The incorporation of XML into POV is secondary, IMHO, to this separation
of scene primitives and algorithmic description.

>  Ultimately, symbols mean what you want them to mean. Of course it's
>possible to use XML to describe scenes - just like it's possible to write
ray
> tracers in COBOL.  But why?  *Possible* isn't enough for me - I want
*easy,
>elegant, effortless and enjoyable.*


I want the same.  I want it now, AND I want it in 5 years time.

>Perhaps XML would be useful as an intermediate language between
>programs, though I don't see how it would be a good choice.  There are
>simpler ways to describe geometry, textures and scenes already in use.
>If someone wants to use XML, okay, but I dont' want to see it.


>Eventually, of course the geometric model really does become a large number
>of independent objects in POV-Rays data structures, suitable for
hit-testing
>and rendering.  It would be neat if POV-Ray could directly read this level
>of data in - but i suspect XML would require much more effort than some
>format that is command-oriented, saying in effect "Create Cylinder with
>radius=xxx, endpoints=..."  You know, with *VERBS*...
>
>Are we seeing in this thread a contrast between POV-Ray users who are
>more mathematically minded - who usually prefer static descriptive
>models of things, using logical categories and relations, and those
>who are deep down primarily artists - who perhaps prefer ACTION,
>MOTION and MEANING but don't mind trying describing these
>mathematically as pov script?
>
>IMOH, we must cater to artists, not to parser writers.
>
>
>
>Final thought:  What if the same argument for marking up scene files as
>XML were to be applied to  C++?  Syntaxic elements of C++ source
>files could be made into XML tags - what would that look like?  Would
>anyone like that?   Scary...


I would love to be able to analyse my source code as XML documents.  This
would be a great step towards full literate programming - which of course
Don Knuth has been working towards for quite some time...

Nick Drew.

Post a reply to this message