Re: [mmox] XML serialization

"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Tue, 24 February 2009 18:04 UTC

Return-Path: <infinity@lindenlab.com>
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 6379C28C203 for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 10:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_LOW=-1]
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 CpLjUILqgNMV for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 10:04:29 -0800 (PST)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id CFC3D28C23F for <mmox@ietf.org>; Tue, 24 Feb 2009 10:04:01 -0800 (PST)
Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 9821F3DBC44E; Tue, 24 Feb 2009 10:04:20 -0800 (PST)
Message-Id: <A67B4EDB-E3E4-4F21-A0CA-A29876F12FA5@lindenlab.com>
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: Catherine Pfeffer <cathypfeffer@gmail.com>
In-Reply-To: <ebe4d1860902240551l2ab28b43o6d391fb1d455cacf@mail.gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 24 Feb 2009 10:04:18 -0800
References: <ebe4d1860902240551l2ab28b43o6d391fb1d455cacf@mail.gmail.com>
X-Mailer: Apple Mail (2.930.3)
Cc: mmox@ietf.org
Subject: Re: [mmox] XML serialization
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 18:04:30 -0000

yes. several alternatives were considered.

it was noted, however, that...

* the difference in space between the existing standard and something  
like what's proposed here, after applying gzip is minor. (this is  
germane because we expect people to use compressed content encoding if  
they care about bandwidth utilization)
* the difference in parse time is negligible as it turns out you  
either have to parse angle brackets or parse <attribute>=<value>  
inside an element.
* the DTD as it's specified now was considered "easier to code" by the  
person tasked with implementing it
* many of us did not like the idea of making the content of an  
attribute and the name of an element co-dependent, as Zero explained  
in a different email

i'm also a bit confused... what's the difference between

<value type="integer" size="128">99992123123123</value>

and

<integer size="128"> 99992123123123</integer>

???

i might be mis-reading you, but it sounds like you're saying the  
former allows you to add a size attribute, but the latter doesn't.  
which can't possibly be what you're suggesting because i just put  
myself in the situation of having to extend the XML serialization in  
the future and added a size attribute to the integer element and the  
world didn't come to an end.

On Feb 24, 2009, at 5:51 AM, Catherine Pfeffer wrote:

> (Infinity: there is a question for you at the end of this message)
>
> Jon said:
> > A better way is
> >
> > <map>
> >    <value type="boolean" key="success">true</value>
> >    <value type="string"
> >         key="something_i_like_to_eat_on_sundays">bananas</value>
> > </map>
> >
> > natural way to express it.This has less of the angle bracket tax,  
> and it
> > has a VERY straight-forward parsing style. In fact, in my opinion  
> it's
> > the most In XPath, it's now trivial: "value[@key=success]"
>
> Yes. I had thought at this solution too, but I had hesitated to  
> propose it straight away to the mailing list...
>
> This solution has fewer angle bracket tax, but it also has hidden  
> implications. I assumed (perharps wrongly) that the authors of the  
> XML serialization had seen these implications, and rejected this  
> solution because of these implications.
>
> Moving tags (<key>, <boolean>, <string> and so on) to attribute  
> names or values is not an innocent operation. Here are the  
> consequences I can see:
>
>
> 1) To allow validation of the allowed types, the new "type"  
> attribute would need to be declared as an enumeration in the DTD or  
> schema.
>
> No big deal so far.
>
>
> 2) More of a problem: if using XML schema for validation, it is more  
> straightforward to check that
>       <float>3.14</float>
> and
>       <integer>42</integer>
> are correct, than to check that
>       <value type="float">3.14</value>
>       <value type="integer">42</value>
> are correct.
>
> (XML schema allows for checking that the data inside the tags  
> conform to a certain syntax, for example that floats are made of  
> digts and possibly of a decimal dot and a minus sign).
>
>
> 3) The key ("success" or "something_i_like_to_eat_on_sundays") is  
> not part of the data flow anymore, but part of the markup.
>
> There are half-religious wars inside the XML world according to what  
> should be an attribute and what should be text ;-). Personally, in  
> this case, I would say that an attribute is more suited to this kind  
> of data, because then we could enumerate all the allowed values for  
> the virtual world context ("name", "taper_x", "socks",  
> "notecard_encoding", whatever is normalized on top of VWSD), so I  
> see this as an advantage of your solution.
>
> On the other hand, if I understand well, LLSD has been defined to  
> allow keys to evolve rapidely and to be supported differently across  
> various implementations, so validating the key values is perharps a  
> bad idea.
>
>
> 4) Other advantages of your solution, Jon: default values for  
> attributes could be omitted, and we could address size and signed- 
> ness of the scalars in separate attributes.
>
> Examples:
>          <value>42</value>
> would be synonymous of
>          <value type="integer" size="32" signed="yes">42</value>
>
>          <value type="float" size="64">3.14159265353238</value>
> would be synonymous of
>          <value type="float" size="64"  
> signed="yes">3.14159265353238</value>
>
> Of course, there is a lot to spare on the angle bracket tax here,  
> since most data is probably integer, 32 bits,, and signed).
>
> It is also more future-proof, since 'size="128"' could be added  
> afterward easily, even if not planned initially.
>
>
> > I'm working on a list of the things I think are wrong with the  
> current
> > proposal, of which this is one thing (there are about six). If we're
> > open to change on those things (including this), then I could get  
> behind
> > the LLSD. Stay tuned :-)
>
> I have a similar list too ;-). Someone here has proposed a VWSD  
> working group to separate high level concerns (like meshes versus  
> prims) from low level concerns (like data types and serializations).  
> If we are sure that xxSD is the way to go (and not ASN or whatever),  
> I would volunteer to be part of such a group, and so would you, Jon,  
> I guess ;-).
>
> Infinity, how was the XML serialization thought? Have several  
> alternatives been compared and considered carefully? Or is it just  
> the result of the inspiration of the person who made it at a given  
> time?
>
> -- 
> Cathy
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox