POV-Ray : Newsgroups : povray.pov4.discussion.general : Reviving some pov4 discussion : Re: Reviving some pov4 discussion Server Time
25 Apr 2024 19:48:48 EDT (-0400)
  Re: Reviving some pov4 discussion  
From: clipka
Date: 11 Dec 2015 10:04:05
Message: <566ae5e5$1@news.povray.org>
Am 11.12.2015 um 01:20 schrieb Mike Horvath:
> On 7/30/2015 6:15 AM, Warp wrote:
>> Some of these are things I have discussed years ago, but I thought it
>> could be useful to revive the discussion a bit.
>>
>> One of the original plans for POV-Ray 4 was to make a complete rehaul
>> of the SDL from scratch, making it a lot more versatilve, expressive,
>> powerful and faster (via byte-compilation). This would have been a
>> completely new input language that's different from the current one
>> (but with, perhaps, a backwards compatibility mode to support existing
>> scene files.)
> 
> I think basing things of SVG would be a good idea. I.e. XML + SMIL +
> JavaScript.

Abso-bloody-lutely not.

XML is quite useful for the static description of purely hierarchical
structures comprised mainly of textual information; for anything else,
it is overly verbose and/or excessively difficult to employ.

A POV-Ray scene is indeed, in essence, a description of purely
hierarchical structures; however, that's where the applicability of XML
ends:

- The information in a POV-Ray scene is mostly non-textual, which means
that much of the overhead XML introduces is entirely unnecessary (such
as the enclosing of tags in angular brackets, or of attribute values in
double quotes).

- POV-Ray's current SDL excels (arguably not in speed, but certainly in
flexibility) in the dynamic generation of scenes; its description of
information is non-static, and a successor to its SDL should indeed
provide the same feature with similar ease. XML is poorly suited for
that: XML-based notations for control structures tend to be excessively
complicated.

The grafting of JavaScript on top of XML (or, more precisely, into its
bowels) does provide a way of generating information dynamically with
more ease than XML alone would allow; however, this is nothing more than
a makeshift solution -- one that has caught on, I give you that, but
that doesn't mean it's anywhere close to elegant: You do need to learn
two entirely different languages, XML and JavaScript.

In fact, the fusing of XML and JavaScript is as ugly a chimera as it can
possibly get: Some valid (and in fact pretty much essential) JavaScript
operators are invalid as XML content; as a matter of fact, /all/
characters that are invalid in XML content may occur as operators in
JavaScript. Thus, embedding arbitrary JavaScript into XML is only
possible via a workaround that hijacks XML comments - which should
normally be ignored - to contain relevant content. And even then, it is
possible to write JavaScript code snippets that break the mechanism by
which they are embedded into XML.

The only clean solution to this problem is to let the JavaScript
portions reside in entirely different files; but that defies the whole
purpose of having a unified language to describe content in a dynamic
fashion.


When it comes to data exchange formats, rather than XML, a much more
suitable candidate for a future POV-Ray SDL would be JSON. But even
then, I think it should only serve as a source for inspiration, rather
than being employed "out of the box".


In my opinion it remains a fact that the best language for POV-Ray would
be a domain-specific language (and by that I don't mean a
domain-specific abuse of an existing language like Apache Camel's DSL,
but a genuine language in its own right).


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.