Re: [vos-d] Re: sample VOS XML

2005-10-26 Thread Peter Amstutz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 26 Oct 2005, Neil Mosafi wrote:


How about calling it ReferenceUri or something similar?


Keep in mind I'm trying to keep this succinct so that actual people won't 
tear their hair out when writing it by hand :-)  I think a lot of the 
success of HTML had to do with the fact that most of the tags are highly 
abbreviated, which makes it easier to type by hand.



On 10/26/05, Lalo Martins <[EMAIL PROTECTED]> wrote:


And so says Reed Hedges on 10/26/05 05:08...

What the hell does "href" mean? ;)


The "h" is for hyper or hypertext or somesuch.

best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
--
http://www.exoweb.net/ mailto:[EMAIL PROTECTED]
GNU: never give up freedom http://www.gnu.org/


___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d





[   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)

iD8DBQFDX4zdaeHUyhjCHfcRAqXAAJ0czYDd9Z3dhLcGauIeEWxWOtLkxACbB15K
DmhWtXspIA9bg8Sn7LL+6H0=
=zs+Q
-END PGP SIGNATURE-


___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Re: sample VOS XML

2005-10-26 Thread Neil Mosafi
How about calling it ReferenceUri or something similar? 
On 10/26/05, Lalo Martins <[EMAIL PROTECTED]> wrote:
And so says Reed Hedges on 10/26/05 05:08...> What the hell does "href" mean?  ;)
The "h" is for hyper or hypertext or somesuch.best,  Lalo Martins-- So many of our dreams at first seem impossible,  then they seem improbable, and then, when we
  summon the will, they soon become inevitable.--http://www.exoweb.net/  mailto:[EMAIL PROTECTED]GNU: never give up freedom 
http://www.gnu.org/___vos-d mailing listvos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Re: sample VOS XML

2005-10-25 Thread Neil Mosafi
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.
 
Regards
Neil
 
  
On 10/25/05, Peter Amstutz <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-Hash: SHA1On 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>> look:>> 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:# Site consists of one or more root vobjects  - Vobject: worldType: a3dl:sector# (optional) defines access control policy for this vobject and#  all children that don't define their own access control policy
Acl:  - Policy: core:accept-all,property:deny-all- Member: /phred- Member: /barneyChildren:# Shorthand for defining a child vobject property  - Property: example
Datatype: text/plainData: Data goes here# Link to a vobject on a remote site  - Link: bloxxTo: vip://interreality.org/bloxx
# Link to a vobject on the local site - Link: that-guyTo: /phred# Can also specify a child object and supply datablocks (so it is# loaded via the persistance interface)  - Child: another-example
Type: property:propertyBlocks:  - Name: property:dataData: Hello there  - Name: property:datatypeData: text/plain# Child nodes are processed recursively the same way as vobject nodes
  - Child: an-objectType: 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:colorData: .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:avatarNumber of lines in XML: 45Number of of lines in YAML: 53This 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 bethat there are restrictions in the data model that I'm not seeing, whichwould 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 myexperience whitespace sensitivity just makes tasks like cutting andpasting 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, whenyou start inserting comments and empty lines, or a data block becomesparticularly large, it becomes increasingly hard to keep track of
indentation level.  So I don't feel it is huge advantage in readabilityand editing that people make it out to be.My second issue is that it doesn't seem to directly support the notion ofa "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, whereeach 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 theschema language yet).Third, it's not clear there is even a working C++ or C implementation of aYAML 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 HyperVOSworks 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 thesyntax.* 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

Re: [vos-d] Re: sample VOS XML

2005-10-24 Thread Peter Amstutz

-BEGIN PGP SIGNED MESSAGE-
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
look:


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:
# 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
Acl:
  - Policy: core:accept-all,property:deny-all
- Member: /phred
- Member: /barney
Children:
# 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
Blocks:
  - 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 ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDXZr5aeHUyhjCHfcRAkmAAKCNRUUVDj7Mv4VEwZ6LNyMJ8Gs2qgCghe8q
FYn35W4