Re: [mmox] xxSD working group?

Christian Scholz <cs@comlounge.net> Tue, 24 February 2009 14:57 UTC

Return-Path: <cs@comlounge.net>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9746D3A6AA5 for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 06:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_36=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le5gfdMOYCEp for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 06:57:18 -0800 (PST)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 0118D3A67A2 for <mmox@ietf.org>; Tue, 24 Feb 2009 06:57:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 912C91CE028B; Tue, 24 Feb 2009 15:57:36 +0100 (CET)
Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32HmZGwBU6mr; Tue, 24 Feb 2009 15:57:35 +0100 (CET)
Received: from [192.168.1.20] (p5B395609.dip.t-dialin.net [91.57.86.9]) by post.comlounge.net (Postfix) with ESMTP id A8EAB1CE00CD; Tue, 24 Feb 2009 15:57:33 +0100 (CET)
Message-ID: <49A40ADA.2080309@comlounge.net>
Date: Tue, 24 Feb 2009 15:57:30 +0100
From: Christian Scholz <cs@comlounge.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Catherine Pfeffer <cathypfeffer@gmail.com>
References: <ebe4d1860902240640u4e24ac2an5d4a2686286eb40e@mail.gmail.com>
In-Reply-To: <ebe4d1860902240640u4e24ac2an5d4a2686286eb40e@mail.gmail.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: mmox@ietf.org
Subject: Re: [mmox] xxSD working group?
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 14:57:19 -0000

Catherine Pfeffer wrote:
> Infinity wrote:
>> Catherine... Jon...
>>
>> can you create a proposal for a next generation XML serialization?
> 
> Yes I can.
> 
>> the existing serialization is in current use by SL, OpenSim and PyOGP, 
> 
> Really? I am surprised to hear that, because I had once the curiosity to
> run Wireshark to sniff packets exchanged by my Second Life client with
> the simulators, and I saw that the binary serialization was used all the
> time, even when using the new capacities system. Could you please point
> me to a situation where I could test the existing XML serialization?
> 
>> so there's probably going to be a lot of resistance to changing  
>> something that currently works and is deployed.
> 
> Infinity, we need to make once for all clear whether this is just a
> Linden Lab existing technologies rubber stamping work group, or if we
> are designing vendor independent protocols for the 3 dimensional web of
> the future.
> 
> While I agree there is no reason to throw away existing stuff (like
> LLSD's simplicity) when it is cool, I think that every bit of the
> technology should be evaluated, and replaced when it has conceptual
> flaws in it.

I also wonder if we not first should think about a general architecture
and then check all the fields if we can use existing formats or not and
if not, what the requirements are our inventions need to fulfil.

> If you disagree with this position, please state it clearly, and I would
> be happy to withdraw from this mailing list and to go to other projects
> where I might be more useful. Similarly, if Linden Lab's position is
> "let them speak and then enforce our own stuff at the end", please also
> spare my time.
> 
>> keep in mind, however, that OGP does not use XML to represent it's  
>> PDUs, it uses LLSD. XML is one of three defined serializations of  
>> LLSD. it's a subtle difference, but important.
> 
> I have it in mind, even though the rationale for using three different
> serializations is far from being clear to me.

I also wonder how much the "normal" programmer will understand this.
Most likely they will skip the LLSD step and directly output the XML or
parse that. It might not be good but if this thing gets widespread it
will certainly happen.

>> for instance... is there a benefit to explicitly adding support for  
>> namespaces to the XML serialization?
> 
> That's a very good question. What would be the purposes of such namespaces?

I wonder this, too. Especially if this is just a serialization layer.
What do you do with namespaces if you deserialize to LLSD? What happens
to them if you then serialize again into a different format?

Maybe some XML representation is really all which is needed. One might
also look at OpenSocial where they have two formats, ATOM and JSON and
rules for translating one to the other. Maybe even ATOM is usable as a
base here.

Also remember that adding new concepts/terms/names to something will
make it more difficulty to understand. If it's just XML or JSON or
whatever is in use already, it's easier to understand and it might get
more adoption.

>> there was a bit of discussion  
>> about this amongst some AWG members, and the consensus was... "why  
>> bother? the XML (presentation layer) is not the place where you want  
>> to extend the PDU... you want to extend it in the LLSD / LLIDL  
>> definition of the interaction."
> 
> Makes sense.
> 
> But this reasoning apparently assumes that the namespaces would be used
> to extend the interoperability standard.
> 
> Normally, namespaces are rather used to mix data from different standards.

Well, I know a lot of places where it's used to add additional
attributes etc.

> That could be *very useful* if we want to mix LLSD for example with a
> mesh description expressed in another standard. Or to be able to include
> SVG graphics. Etc. While this would be very powerful, that would not
> scale back to the two other serializations, because it's pure XML
> mechanisms.

Right. But you might say that such a mesh is stored in one field (tag
then) and you can simply copy the whole XML part over to this field in
e.g. a JSON structure. But that might be somewhat messy ;-)

But actually I really would first think about a more global approach
towards a general architecture and then defined the more details
protocols and formats needed.

-- Christian

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge                                   blog: http://mrtopf.de/blog
Luetticher Strasse 10                                    Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail cs@comlounge.net
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)