OK I know (unfortunately) I've not been paying huge attention to recent VOS going ons but I would say that I'd be highly inclined to go down the XML route here. As you said, XML is pretty much the norm nowadays for describing any form of arbitrary data. Other reasons I can think of for going with XML are:
- XML can be validated (using XSD) and transformed (using XSLT), which could both prove to be useful for VOS in the future
- XML parsers exist for every platform out there from PDA to supercomputer!
- Syntax highlighting is built in to most editors (vi, notepad2, textpad, visual studio etc). Some of these can even link to the XSD file and can provide you real time validation as you type
- There are also lots of XML editors out there which can give you a graphical or collapsable view of your XML configuration file
- There are lots of other bolt-on technologies and standards related to to XML, such as XML signing, XML encryption and SOAP web services.
On 10/25/05, Peter Amstutz <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
# (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
Data: Data goes here
# Link to a vobject on a remote site
- Link: bloxx
# Link to a vobject on the local site
- Link: that-guy
# Can also specify a child object and supply datablocks (so it is
# loaded via the persistance interface)
- Child: another-example
- Name: property:data
Data: Hello there
- Name: property:datatype
# Child nodes are processed recursively the same way as vobject nodes
- Child: an-object
- Property: a3dl:position
Data: 1 2 3
- Property: a3dl:orientation
Data: 0 1 0 90
- Child: a3dl:material
- Property: a3dl:color
Data: .3 .5 .7
# Can define additional vobjects which are not connected to the
# first vobject
- Vobject: phred
- Vobject: barney
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
* 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 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
-----END PGP SIGNATURE-----
vos-d mailing list
_______________________________________________ vos-d mailing list email@example.com http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d