On Mon October 22 2007 10:15, Don Dailey wrote: > almost impossible to write XML manually without bugs.
it also seems to be hard to write an SGF file without bugs. I recently run a test on a collection of about 5000 SGF files from various sources on the web and more than 20% of them generated a warning when reading with GoGui. The most frequent problems are duplicate properties or root-properties in non-root nodes. Another problem I have with SGF is that it allows user-defined properties. While this is very appealing at first, because it allows to preserve unknown properties, it creates problems in practice. One is the potential of conflicting property keys, because there are no namespaces. Also, if a program does not know, what a property means, it cannot do much apart from preserving it when saving the file. But of other properties of a node were changed, the unknown property could have lost its context in which it is meaningful. I agree that reading an XML file without using a library is complicated, but there are enough libraries existing and even part of the standard libraries of some languages. The big advantage of an XML-based file format is that it leverages the power of meta-tools. Like it is a big advantage to use line-oriented text-based file formats on Unix, because you can do a lot of tasks simply using standard tools, like grepping, transforming, diffing and merging. But line-oriented text-based file formats reach their limits when you have data with a more complex structure, like trees. Think of resolving a conflict in a Go game file in your version control system. If the file format was XML-based, a meta-tool could merge changes like version control systems do right now with text-based files. Do you want to write a different conflict-resolvers for every file format? Or hava a look at this XSL style sheet: http://homepage.ntlworld.com/daniel.gilder/gosvg.html It creates a nice looking SVG vector graphic from a Jago XML file and the whole transformation is done by a standard tool with the transformation again described in an XML data file. - Markus _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
