> 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] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message