|
 |
(crossposted from povray.general - "The Language of POV" thread)
If you've got an itching, an interest, or a burning desire
for XML based POV data storage, speak now. Please don't
recycle the flames from the previous thread... :-)
What I would like to do is develop a proposal - do more
conceptual development, demonstrate more advantages,
consider the implications for the Povray architecture.
Ken Tyler on the idea of XML for Povray:
> > If there are other people who find these
> > possibilities attractive, I would be interested
> > in developing a more detailed proposal. Some
> > aspects would require interaction with the
> > POV team, or the TAG people - but I think it's
> > fair to present them with more than a
> > "we think XML is funky idea" or have them
> > sift through threads of conceptual development
> > and hysterical backlash.
>
> Speaking as a TAG member I will offer this advice. If you can get other
> people excited about your ideas, and between you draft a concrete proposal,
> I would be happy to present it to the POV-Team on your behalf for their
> consideration. It would really help if you could figure out a way to make
> all of us understand the ramifications of your proposal, and get us excited
> about it, but if you are sure it has merit I/we will not stand in your way.
>
> What you need to bring to the table -
>
> 1. Detail your proposal as far as functionality and purpose.
>
> 2. Describe in detail what advantages your proposal has over the current
> system.
>
> 3. Who benefits from the changes or additions of your proposal.
>
> 4. Try to give some indication of how difficult it will be to implement
> and what kind of language support will be needed to make it portable
> to all platforms that POV-Ray currently supports.
>
> Remember that if you cannont get other people here excited about your
> proposal there is little likelihood the POV-Team will get excited about
> it. Also remember that timing may be everything. Right now the POV-Team
> is actively working on finalizing the release of POV-Ray v3.5 which for
> all intents and purposes should be considered feature locked at this time.
> This means from the POV-Team's point of view any action they might take
> towards your proposal will have to wait for their planned C++ re-write
> for POV-Ray v4.0. As far as I know the POV-Team has not entered into
> any detailed discussions on what changes will be made in v4.0, other
> than the move to C++, and it is likely they will want to have their own
> data structure decided before accepting additional suggestions in this
> regard. Their internal discussions will likely be sometime down the
> road when the release of POV-Ray v3.5 has been made public and they have
> had a chance to hammer the public reported bugs out of it.
>
> Keep this in mind...
>
> What you are proposing may actually be better suited for a dedicated
> patch of the program rather than something the mainstream POV-Ray user
> will be interested in having in the official version of the program.
The previous post:
> So what exactly are you suggesting? That POV should use XML for data
> representation and should internally convert POV-Script to XML as well
> as supporting XML input?
I've been giving this some thought today, pondering the
technicalities as well the unexpected hysteria generated
on povray.general and the IMP list. Every day I go to
work improving a software product, trying to deliver the
features that users are asking for. I get a lot of
satisfaction from finding elegant, robust and user
friendly solutions to new problems. But, in the context
of povray, the mere suggestion of some kind of paradigm
shift seems to upset people very quickly.
Anyway - here is a more concrete model of how I think
povray data input should be handled. There needs to
be a clean and simple interface between the POV parser
implementation and the core POVray raytracing engine.
This API might look like a bunch of simple functions
such as "bool insertSphere(...)" which is as minimal
as possible, while supporting all of the POV data types.
Things like loops, variables and macros should be
strictly layered above this API. This API would also
make a nice DLL interface, eventhough the POVteam
don't like the idea of POV being used as a library.
The existing parser simply becomes one possible user
of this API. Text editing die-hards can do whatever
they please, without any threat from trendy programmer
types who want to do different things. Another user
of this API could be an interpreted C environment,
POV-CSDL, XML, or whatever takes people's fancy.
The POV-team control the "official" API, but allow
people to build on top of it freely. Ideally, the
API is also made available as DLL so that Java, C,
Delphi, etc programmers can do whatever they like,
in the language of their choice.
This handles input. Another question is output -
would it be useful and desirable to provide some
mechanism to extract the state of a POV world
at runtime? Maybe, maybe not. I do not intend
to deal with this at this stage.
Before closing, a few points about an XML pov
that perhaps have not been stated clearly:
XML is certainly not customised for the problem
of text editing descriptions of 3D scenes. It's
not bad, but it's not ideal.
XML is a mechanism that would allow third party
tools to manipulate POV scenes. You load the
data in, edit geometry, textures, etc, then
save the data out. One critical limitation in
POV script is the difficulty in parsing it.
In some ways, POV script has been so heavily
optimised for hand editing (in addition to
the macro and looping constructs) that it
is much more complicated than it needs to be
for many other tasks.
XML is a mechanism that simplifies extension.
You don't need to be a parser expert to define
new data types, or to add attributes to objects.
Because the grammar is less ambigous (taking
advantage of verbosity) an XML parser can
ignore irrelevant data - but preserve it.
Backwards compatibilty in a scheme like POV
script is a more difficult problem.
XML allows POV to take advantage of related
technology such as VRML. To support VRML
datatypes, we simply borrow the grammar -
no parser programming necessary. To support
a new procedural texturing architecture, we
borrow their grammar, no parser programming
necessary. (There is a big difference between
writing a parser and writing handlers for
an XML parser)
If there are other people who find these
possibilities attractive, I would be interested
in developing a more detailed proposal. Some
aspects would require interaction with the
POV team, or the TAG people - but I think it's
fair to present them with more than a
"we think XML is funky idea" or have them
sift through threads of conceptual development
and hysterical backlash.
XML is of immediate commercial interest to me
for other projects, so I can justify a lot of
time as developing expertise. ("homework")
I think that there should be at least a
group of people involved, and a healthy
discussion, in combination with some
public relations. If you think that XML
is an interesting technology to apply to
POVray, are just curious about XML, I would
encourage you to drop me an email.
XML does not mean manual editing of tags
in a text editor. People that keep harping
on this are just being silly. But I am quite
convinced that text editing should become a
thing of the past. (I never can remember
the RGB or even name for "that favorite
blueish grey" that I always like to use, nor
should I have to remember junk like that.)
--
Nigel Stewart (nig### [at] nigels com)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
