|
![](/i/fill.gif) |
In article <Xns94B59926AB1ABZenZenPsychocom@203.29.75.35>,
Zen### [at] ZenPsycho com 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
|
![](/i/fill.gif) |