Re: [mmox] XML serialization

Jon Watte <> Mon, 23 February 2009 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B81128C243 for <>; Mon, 23 Feb 2009 15:02:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4rJlgDVVIskH for <>; Mon, 23 Feb 2009 15:02:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 774D528C242 for <>; Mon, 23 Feb 2009 15:02:55 -0800 (PST)
Received: by gxk22 with SMTP id 22so5908840gxk.13 for <>; Mon, 23 Feb 2009 15:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=kMkMRwV5A5J/28Y/rkxiE2i0WhjhYCXEB+11hBp7Jpc=; b=gG1AsGYhgVTca0HQ8uUxmiA4WiGTrMPiUTpWtUWfETHk5nIQaOHQZaEqyTqFJ3skP+ c1ZgkM6EOJ8CF/wG8MMP0DH/Vf6IWd6GO9TUWhP5Vw9YBzT/3SrSbMhs2G+Dy36wqwTI LaVntAk581JvAwUVojDzC/XFIjIJNYunJAFbw=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=EMXW1M/bYjQEdLQEBw4gyrPp2fPj4EhQPFZo5CCSOslwneq5mgHAhIJ/Kj/pPtrCvy rbfmFWrtiTPH7SNVfMNxXog6VUGfopq06FbAzvl6LBGlzmb/iFaVgeg2r1ASfZ68p41Y +w5pzozWv4hVSJQ4XiPN9qufXcpoA9pWs2Ihs=
Received: by with SMTP id l10mr4903973and.25.1235430192792; Mon, 23 Feb 2009 15:03:12 -0800 (PST)
Received: from ? ( []) by with ESMTPS id c9sm5798357ana.13.2009. (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 15:03:12 -0800 (PST)
Message-ID: <>
Date: Mon, 23 Feb 2009 15:03:10 -0800
From: Jon Watte <>
User-Agent: Thunderbird (Windows/20081209)
MIME-Version: 1.0
To: Mark Lentczner <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [mmox] XML serialization
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Feb 2009 23:02:56 -0000

Mark Lentczner wrote:
> Jon Watte wrote:
>> <map>
>> <value type="boolean" key="success>true</value>
>> <value type="string" 
>> key="something_i_like_to_eat_on_sundays">bananas</value>
>> </map>
> This format is notably more difficult for schemas (from XMLSchema to 
> RelaxNG) to support, since value now has a key attribute that is only 
> valid iff it is tested in a map element.  Second, you have left out 
> the top element, which needs to be something fixed, rather than being 
> map or array or value depending on the structure of the data.

Yes, my illustration was only an illustration of how to turn a tag-fest 
into something more useful.

> Including a type attribute also makes things difficult for schemas, as 
> the content of the value element now depends on the value of one of 
> it's attributes.

I don't think you can verify the content of any element absent the 
actual executable code endpoint. Trying to do that in schema is pretty 
useless IMO. For example, if we have a "float64_3" type for global 
position, then perhaps a schema validator could verify that the content 
of that element would be three float64 values separated by commas 
(assuming that's the defined serialization), but there would be no way 
for the schema to validate that that position was actually semantically 
valid within the target context, because that's a simulation property.

> Including the key value as an attribute value will make this somewhat 
> harder to edit in some systems where "human readable" text is 
> generally much easier to handle as element content.  Keeping the key 
> value as element content also keeps the processing with key values 
> consistent with the processing of string values with respect to string 
> handling including normalization.

My experience is the opposite. Hence, my proposed change :-)

Also, my suggested serialization is invariant to child node re-ordering. 
Most of the time, that's not important, but for some cases, where a tree 
might be put into a hash map for fast access, it matters. 
Not-order-specific XML is generally faster to parse and more robust, 
when you can actually assume it's non-order-specific.

I'd be comfortable with backing off to say that the element tag name is 
the data type, while key is still an attribute, but from my experience, 
putting the type as an attribute as well actually works out better in