[mmox] Requirements for new xxSD specification

Catherine Pfeffer <cathypfeffer@gmail.com> Tue, 24 February 2009 15:29 UTC

Return-Path: <cathypfeffer@gmail.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 F3AD73A6836 for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 07:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.237
X-Spam-Level:
X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 t6MC62pLi7GN for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 07:29:26 -0800 (PST)
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id B83273A6820 for <mmox@ietf.org>; Tue, 24 Feb 2009 07:29:25 -0800 (PST)
Received: by ug-out-1314.google.com with SMTP id j40so252045ugd.15 for <mmox@ietf.org>; Tue, 24 Feb 2009 07:29:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=MISq53lEo0rLBsnI7MBaW+23dspi1jg85Cv91J6U+Rs=; b=dud3nR0QzLIWit9RTSzgNKTTf/lUOYjfq3E0+KdagiUCLgIigcIIBX/aVoNTIVDAPZ IGPqyR0BQdU5QAPFUBFXxu/llUjQyU7nEfLIGOyOL2oyomUn9SY6pm937dQfaDsptXat zbjFgcDW9tNX9J9pIN575LM6MNQClrJdGNX+s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VOdvMMEr3BuWnqouLBbVmQWAXAFgKiW/LG00nU0K7tIWmtkNKeBJPWxpF38krksfTB JE06m4ZeDKFPvIB1gMCqBWqV9+KhE9o7TB5JQxCpw+wW4QGFGfUSSLyBKzl8J2XJUaZk bbTd4kPpyfZ1zws41mqj0M1/v2omZqRWcSvXQ=
MIME-Version: 1.0
Received: by 10.210.54.15 with SMTP id c15mr4471257eba.139.1235489383479; Tue, 24 Feb 2009 07:29:43 -0800 (PST)
Date: Tue, 24 Feb 2009 16:29:43 +0100
Message-ID: <ebe4d1860902240729x5e86306bpd0950b05c3a11f28@mail.gmail.com>
From: Catherine Pfeffer <cathypfeffer@gmail.com>
To: mmox@ietf.org
Content-Type: multipart/alternative; boundary=0015174beb3ad379f60463abc986
Subject: [mmox] Requirements for new xxSD specification
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 15:29:27 -0000

Infinity wrote:
> so my response would be:
>        1.a. can we look at the effect before making this change? my
> suspicion is that message sizes will be much more affected by turning
> on compressed content encoding than with the change from one DTD to
> another.

Of course. Whatever we come up with, it must meet the following requirements
:
1 - be easy to validate with a schema or DTD
2 - be easy to parse and transform  with XSLT and XPath
3 - have low "angle bracket tax" price to pay
(and that should be expressed as a precise "bloat ratio" relative to the
binary serialization for the same set of data)
4 - be future-proof, i.e. allow for things that have been identified as
missing, like lack of alternative sizes for integers and floats, and lack of
unsigned.

I also have a detail question/concern about the current LLSD serialization.
What is the intention on how to serialize big amounts of data, like an
avatar mesh or a PNG picture? Are they supposed to go into a big
<binary>...</binary> blob? Because, if that is true, the binary data encoded
so will have to be base64-encoded inside of the <binary> tags, and that's a
point that might make the whole XML serialization almost unusable, because
the angle bracket tax would probably become unacceptable in typical data
exchanges.

-- 
Cathy