> >       I mean that once data is stored in POV format,
> >       it is trapped there.
> 
> I understand what you were trying to say now, but I still don't see why
> it is a problem. If the program already has the data, why does it need
> to read it back?

This solution:
	Implement a custom file format in ASCII, that only your util
	and your POV macros can understand.  What happens when I feel
	like shifting this same data to Autocad?  Or into my own
	CAD/CAM software?  Write more code to emit a different format?
	Is is not my idea of efficient software development.

XML solution:
	Use a format that is standard, flexible, extensible, and that
	other applications have a decent chance of importing.
	
> And besides, you can always use a plain comma delimited text file to
> store the data, and use macros or an include written in POV-Script to
> read it. 

	That sounds absolutely archaic, honestly.

> I really don't think many people "program" in ASCII, but in structural
> concepts and operations which they translate into a language format.

	At the end of the day, the docco and the source is all
	that other people have to refer to.  I would like to have
	the flexibility to add comments which are only visible to
	me, backups of old implementations of a routine, and even
	copies of email, or relevant URL's that serve as a reference.
	Plain old text editing won't cut it.  In some places, I'd
	like to be able to paste VRML examples of special cases,
	or sample output.  Try doing that in a text editor.

> but I don't think I would be able to
> make much sense from a non-code representation of that on the screen.

	So, UML was invented purely as an academic pastime?
	Diagramming packages like Rational Rose were invented
	as some kind of toy?  I've used a HTML documentation
	generator, that converts from C++ sources to nice hyper-linked
	reference documentation.  (Can't remember the name of it)
	It struck me that this was a far superior way to browse the
	source than the clunky stuff in Visual C++, or sifting through
	the files manually.  The only limitation - I can't edit in 
	this environment.  But I want to - desperately.

> Why would you need to? 

	Because I've got better things to do than manually search
	for information, figure out dependencies, track the use
	of variables, or accurately rename all references to a 
	particular function or variable.

> If it is for writing/modifying code, that belongs
> as an editor feature.

	No, it doesn't.  It is related to pre-processing, compiling and
	even linker issues.  Thinking of this only in terms of
	editing is half-baked.

> But you can try to explain the limitations to the people who don't see
> or feel them...(hint)

	I've explained plenty, to you at least.  I do not
	get any impression that you're going away to do
	any homework for yourself.  I am not going to 
	dedicate my life to making every implication
	totally obvious to you.

> >       They are referred to as separate language, but
> >       they are actually so similar that it may be better
> >       to refer to them as "dialects of procedural programming".
> 
> You mean like Chinese and Australian Aborigine are different 
> "dialects of human language"?

	Human languages are much richer than computer languages.
	I think it is a fair stretch to draw comparisons like this.
	The underlying theories in C and Pascal are roughly
	equivalent, whereas the protocols and nuances of meaning
	I would expect to be completely different between Chinese
	and Aborigine.

> My point was that text editors are practically universal, and everyone
> knows how to use them. XML editors are not as universal, and many people
> don't know anything about them.(like me)

	Then learn something. 

> If people are using POV, it is a very safe assumption that they have and
> know how to use a text editor(and a computer, monitor, keyboard, etc).
> The same does not apply for XML.

	As I have said more than once, I have no opposition to
	POV script as it stands.  However, it can not be
	"all things to all people".  This "lowest common 
	denominator" philosophy shouldn't be taken to
	extremes.  I expect that XML based editing will become
	quite common - and most of the time, people won't realise
	they're doing it.  Anytime you enter data on a webpage,
	there is a good chance that there is XML interfacing to
	the database.  

> I don't think XML is a "gimmick", I just don't think it is the right
> thing for POV-Ray. 

	You don't know enough to make this claim, or make this
	judgement.  
	
> If you can demonstrate how it would be the "right
> thing" 

	I've proposed a working group to develop the concept.
	"Conceptual Development" is a normal process which works
	best if it involves many people.  However, it is not
	my intention to crusade for XML.   (Although I suspect
	that nothing would ever be enough to satisfy you)
	POVray is not the only raytracer in town, after all.

> how it would be noticeably more flexible and useable than the 
> alternatives

	A XML based format for POV would be more flexible and
	useable simply because of XML.  It's not optimised for
	hand editing, but frankly that isn't important all
	of the time.

> And you still haven't explained how this gets the data into RAM in an
> easier way than making modifications to a well-written parser would.

	There is no need to me to explain the basic functioning 
	of an XML parser.  I highly recommend it to you as a homework
	problem - I think it would help you understand why programmers
	are no longer interested in "well-written parsers", they are
	interested in getting the parser off the shelf, and focusing
	on the real problems.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message