Stuart--no, I didn't read it that way and I'm sorry that my mail gave the impression that I did.
Bob On 10/27/07, Stuart A. Yeates <[EMAIL PROTECTED]> wrote: > > Bob > > I'm sorry if you read my message as saying that I'm not in favour of > an XML file format for go. I'm actually very much in favour of such a > thing, which is why I spent two hours getting to understand the > current contender and pointing out some of the issues that need to be > fixed. > > cheers > stuart > > > On 10/27/07, Bob Myers <[EMAIL PROTECTED]> wrote: > > Some critics of an XML-based go format seem to be involved in a paranoid > > fantasy that they are going to be forced by evil goblins to use it > against > > their will. No, Jennifer, that's not the case. Sure, if the format > becomes > > popular they may end up having to deal with it, but XML-formatted game > > records and SGF will be round-trippable in the blink of an eye. > > > > Many of those complaining about XML don't seem to really know too much > about > > it. Griping that it's too big is roughly equivalent to wanting to go > back to > > six-bit character encodings. Carping that it's not readable misses the > > point. Those who wonder if their favorite platform/language might not > > support XML haven't checked recently. The point is that XML offers an > > incredibly rich environment of transformability and extensibility and > > interoperability. > > > > Go programmers are mostly interested in move sequence data, and that's > > natural, but we should remember that there are lots of other pieces to > the > > overall puzzle, including commentary, organization of problem sets, and > how > > diagrams are handled. > > > > Let's take just a few examples. Say we want to store metadata in or > > alongside SGF files, and/or retrieve/search/index the metadata already > in > > them, such as the name of the source. If the metadata is in XML, > probably in > > a well-established format such as Dublin Core or an extension thereof, > it > > can be discovered and processed by any search engine or, in the not too > > distant future, reasoning engine, to answer queries such as "find all > games > > played by Shuko in 1971". > > > > In addition, XML has a built-in mechanism for extending vocabularies > > (namespaces). This allows information specific to a particular > application > > to be included in a document, with well-understood characteristics that > > allow other applications to ignore the extra stuff. > > > > DocBook is an example of an XML-based document format for articles and > > books, technical and otherwise, For instance, O'Reilly uses a variant of > > DocBook for all its publishing. Using XML to represent go information > would > > make it much easier to integrate with document formats such as DocBook. > > > > As someone pointed out, using XML would lay to rest once and for all any > > questions about character encodings. It also provides the built-in > xml:lang > > mechanism to represent parallel textual information in different > languages, > > very useful for Oriental players' names, to give just one example. > > > > Many people think of XML documents only as text files, but in fact they > can > > take any form, including being stored in databases which are optimized > for > > performance in executing e.g. XQuery queries. How're ya gonnna do that > with > > SGF? > > > > Many go applications are going to require additional types of > information, > > such as the threaded commentaries mentioned by Bill S. Certainly > compared to > > the option of forking SGF into a dozen proprietary formats which don't > > interoperate, or stuffing random s**t into the C[] field, would it not > make > > sense to take the opportunity to upgrade to a single yet extensible > model > > What say ye, architects of the computing universe? > > > > The XML formats that have been proposed thus far for go, unfortunately, > lack > > imagination; they are little more than SGF with a thin XML veneer. In > > particular, they have the problem that they hang information such as > > commentary and diagrams off the game tree. What we need is a new format > > defined ground-up from an XML perspective. Realistically, putting up > > white-tower proposals is not going to be successful. What is needed is > > real-world proposals on which real-world applications are built, so that > > people can see the real-world benefit. > > > > Bob Myers > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Stuart A. > Yeates > > Sent: Thursday, October 25, 2007 1:04 AM > > To: computer-go > > Subject: Re: [computer-go] XML alternatives to SGF > > > > I sat down and read the DTD and the documentation and have some direct > > feedback on it. I'm aware that the DTD is quite old, and some of the > > ideas and solutions I'm going to suggest might not have been available > > (or as popular) when the DTD was written. Lines starting with <! are > > quotes from the DTD. > > > > <!-- P is the Paragraph of HTML --> > > > > <!ELEMENT P (#PCDATA)> > > > > > > Referencing HTML in this way doesn't allow validation. Defining the > > standard using schemas allow importing of concepts such as "Paragraph > > of HTML" directly from an appropriate HTML standard. > > > > > > <!-- Each Go file consists of one or several GoGame --> > > > > <!ELEMENT Go (GoGame*)> > > > > > > > > I believe it is a mistake not to have a protocol version number here. > > > > > > <!ELEMENT Application (#PCDATA)> > > > > <!ATTLIST Application format CDATA #IMPLIED> > > > > > > It seems unfortunate that there is no explicit version number here and > > no url link to the application website. > > > > > > <!ELEMENT Date (#PCDATA)> > > > > <!ATTLIST Date format CDATA #IMPLIED> > > > > > > It would be great to define this in terms of a standard format (i.e. > > ISO date format), since more than once I've had to infer the > > formatting of a date an SGF file. > > > > > > <!ELEMENT User (#PCDATA)> > > > > > > The user tag is ambiguous, is this a person's name? a user name? a > > user name on what server? > > > > <!ELEMENT Copyright (P+)> > > > > It would be great to use a URL here to the licence under which the > > file is being distributed, for example, the creative commons licences > > on a lot of web content these days. > > > > > > > > <!ELEMENT Rules (#PCDATA)> > > > > <!ATTLIST Rules format CDATA #IMPLIED> > > > > Using a url to a ruleset here would be great. > > > > > > > > Even better would be a machine-interpretable ruleset, but I'm not > > counting on that anytime soon. > > > > > > > > <!ELEMENT Black ((at)*)> > > > > Using schemas allows the content of tags to be restricted. See also > > discussion in the docs. > > > > > > > > > > <!-- This is to take care of SGF tags, which are not translated --> > > > > <!ELEMENT SGF (Arg*)> > > > > <!ATTLIST SGF > > > > type CDATA #REQUIRED> > > > > <!ELEMENT Arg (#PCDATA)> > > > > > > > > This introduces ambiguity into the file format, since it is > > unclear what the precedence is. If the XML says one thing and the > > embedded SGF tags say another, which has precedence. > > > > cheers > > stuart > > > > On 10/22/07, Jason House <[EMAIL PROTECTED]> wrote: > > > An XML alternative [1] to SGF has recently come to my attention. What > do > > > others think of this alternative? Personally, the effect of a tag > > affecting > > > the previous tag seems kind of strange to me. > > > > > > PS: I found out about this from [2], a recently closed GoGui feature > > request > > > to write more sane sgf files that contain the standard algebraic > notation > > > used in all GUIs. > > > > > > [1] > > > http://www.rene-grothmann.de/jago/Documentation/xml.html > > > [2] > > > > > > https://sourceforge.net/tracker/?func=detail&atid=489967&aid=1752711&group > _i > > d=59117 > > > > > > _______________________________________________ > > > 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/ > > > > _______________________________________________ > > 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/ >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
