POV-Ray : Newsgroups : povray.general : Random thoughts about povray and xml : Re: Random thoughts about povray and xml Server Time
3 Aug 2024 14:10:58 EDT (-0400)
  Re: Random thoughts about povray and xml  
From: Patrick Elliott
Date: 24 Mar 2004 00:38:36
Message: <MPG.1acacb571e99ceb19899f3@news.povray.org>
In article <Xns94B59926AB1ABZenZenPsychocom@203.29.75.35>, 
Zen### [at] ZenPsychocom says...
> As for how difficult xml is to parse, well, it doesn't look nearly as 
> difficult to parse as the povray SDL. Once an XML parser is written, I 
> have no idea why anyone would waste time writing it again and again and 
> again for each project.

Actually that would be a misconception. Yes, XML parsers exist, however 
on the most basic level you get something like:

<...> = start tag.
</...> = end tag.
... = ... - attribute.

The specific nature of 'each' individual tag, which tags can or should be 
nested inside other tags, what attributes are actually valid, etc. must 
all be implemented by second level of the parser that *you* have to 
create. Most implementations of XML are all more or less used for the 
web, it is thus fairly trivial to add a few extra tags and some new 
attributes to it, but for something like POV-Ray you would be have to 
implement a completely unique set of tags and attributes. The parser can 
read those out and pass them to your code to decode, but you still end up 
designing your own parser anyway to make sure everything is correct and 
store the objects internally. XML only provides a framework that makes it 
easier for people to identify when related attributes are part of a 
single object and the pre-parser needs to only start and stop the *real* 
parser when the start and end tags appear. It can't describe or provide 
any way for a program to know what to do with any of that information, 
unless it knows what the attributes and sub-tags actually mean.

The fact is that looked at in those terms something like:

box {<-1,-1,-1>,<1,1,1> pigment{color rgb 1}}

becomes:

<box>
  <corners>
    corner1 = -1, -1, -1
    corner2 = 1,1,1
  </corners>
  <pigment>
    <color>
       rgb = 1
    </color>
  </pigment>
</box>

or something like that. All you really end up doing is replacing 'box {' 
or '}' with <box> and </box>, etc. The pre-parser and all the underlying 
code to figure out how to store and use this information is almost 100% 
identical, but the pre-parser that has to decide if/when a box or other 
item starts and ends just ends up reading more characters. The result is 
not any better than the original syntax. In fact, it royally messes up 
vectors, since XML and vectors both use <>, so you have to add a special 
rule that tells the parser to treat certain cases as values or variables 
instead of tags. But what if someone has <box2, 1, 2>? Is that a bad tag 
or a variable? The XML parser has absolutely know way of knowing what you 
intended or what error to return if it is wrong. You end up having to 
have it *guess* what was intended and we have all seen with HTML and some 
of its complicated quirks how well that works. You can 
successfully display pages in HTML that a validator would throw out 
dozens of errors from, because the validator assumes the most strict 
version, even if it can work, while the browser simply ignores anything 
it doesn't understand. We don't need people doing that with an object/SDL 
syntax.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}


Post a reply to this message

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