Hash: SHA1

On Tue, 25 Oct 2005, Lalo Martins wrote:

And so says Peter Amstutz on 10/24/05 01:29...
Alright, I've come around and decided that maybe an XML representation
is the way to go.  Here's a sample file that demonstrates how it might

Yuck.  Can I insist on YAML?  :-P

It looks horrible, and I really don't think XML is the best choice for
*anything* that has to be written, read, and edited by humans.

Ok then, for comparison's sake, here's how it might look in YAML:

# Site consists of one or more root vobjects
  - Vobject: world
    Type: a3dl:sector

# (optional) defines access control policy for this vobject and
#  all children that don't define their own access control policy
      - Policy: core:accept-all,property:deny-all
        - Member: /phred
        - Member: /barney
# Shorthand for defining a child vobject property
      - Property: example
        Datatype: text/plain
        Data: Data goes here

# Link to a vobject on a remote site
      - Link: bloxx
        To: vip://interreality.org/bloxx

# Link to a vobject on the local site
     - Link: that-guy
        To: /phred

# Can also specify a child object and supply datablocks (so it is
# loaded via the persistance interface)
      - Child: another-example
        Type: property:property
          - Name: property:data
            Data: Hello there
          - Name: property:datatype
            Data: text/plain

# Child nodes are processed recursively the same way as vobject nodes
      - Child: an-object
        Type: a3dl:object3d.cube
        - Property: a3dl:position
          Data: 1 2 3
        - Property: a3dl:orientation
          Data: 0 1 0 90
        - Child: a3dl:material
          Type: a3dl:material
          - Property: a3dl:color
            Data: .3 .5 .7

# Can define additional vobjects which are not connected to the
# first vobject
    - Vobject: phred
      Type: core:identity,misc:avatar
    - Vobject: barney
      Type: core:identity,misc:avatar

Number of lines in XML: 45
Number of of lines in YAML: 53

This represents a fairly literal translation of the proposed XML grammar to a YAML grammar. There may be a better way to do it... Or it may be that there are restrictions in the data model that I'm not seeing, which would require expanding the structure a bit more.

Alright, my comments. First off, I'm not keen whitespace-sensitive syntaxes in general. Python (for example) is nice and all, but in my experience whitespace sensitivity just makes tasks like cutting and pasting blocks of code a huge pain in the ass, because it's impossible to have the editor autoformat your code. Also, as you can see above, when you start inserting comments and empty lines, or a data block becomes particularly large, it becomes increasingly hard to keep track of indentation level. So I don't feel it is huge advantage in readability and editing that people make it out to be.

My second issue is that it doesn't seem to directly support the notion of a "associative array" which is at the heart of VOS. It has a sequence type, and a mapping type, but no ordered, associative sequence type. This makes specifying heterogenous lists (such as the child list, where each entry can be an embedded object, a link, or a property) at best a bit less elegant, at worst impossible (I haven't looked closely enough at the schema language yet).

Third, it's not clear there is even a working C++ or C implementation of a YAML parser, and I don't intend to write my own.

Reasons I've come around to XML, despite not liking it initially:

* Parts of VOS were deliberately based on XML DOM -- this is why HyperVOS works so well. So mapping VOS into XML isn't that much of a stretch.

* Everybody and their dog knows XML and is already comfortable with the syntax.

* Rich toolset and library support for every language, OS and platform.

* It's the magical XML pixie dust that makes everything more exciting!!!

I do agree that it's relatively ugly for config files and scripts. However, rather than ditch XML entirely, I'd rather find a way to streamline it as much as possible so that it's less cumbersome. This has been the VOS approach; start with a more generic and powerful design, then streamline the most common cases so that they can be acomplished easily without compromising the general purpose nature of the entire system.

Feel free to argue this point some more, if you think there is anything I've missed :-)

[   Peter Amstutz   ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]  ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
Version: GnuPG v1.4.1 (GNU/Linux)


vos-d mailing list

Reply via email to