Markus Enzenberger wrote: > 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. > 20% of the games or 20% of the sources? 20% of the games could have come from a single source.
In either case, I wasn't comparing SGF to XML, I was comparing it to JSON. > 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. > So are you arguing that you should have no control over properties? Is this a strength of XML that you cannot define properties in a flexible way? > 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. > That's the problem. The constant pressure to add more and more libraries to do simple things in more complicated ways. I don't want to link in yet another library to my code. > The big advantage of an XML-based file format is that it > leverages the power of meta-tools. That's one way to look at it, but it also demands the use of these tools. Suddenly it becomes problematic to use simple tools like an editor. My primary problem with XML is that a big deal is made out of it being "human readable", calling this a virtue but then it's treated as if it were a binary format, requiring the use of libraries and other bloat-ware to deal with it. Not only is it verbose and bloated, but now you must add libraries and more bloat to deal with it. > 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. > There we go again - XML was supposed to be a text-based file format. I don't know what this has to do with using pipes in unix. The whole web thing with html tree's began with unix before most OS's even existed - but how is this relevant? > 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? > What I don't want to do is become a hammer and think everything is a nail. Example: there are those who advocate XML as a programming language. Now this is just about as silly as it gets. There is a language called Superx++ which is written in XML. Superx++ is a buzzword compliant language if I ever saw one. Here is hello world written with this hammer: <xpp> <xout>Hello World!</xout> </xpp> I can't think of any reason I would use this language and I don't believe having to use meta-tools would be enough of an enticement to make we want to use this language. - Don > 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/ > > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
