Re: [mmox] Requirements for new xxSD specification

Lisa Dusseault <lisa.dusseault@gmail.com> Tue, 24 February 2009 21:43 UTC

Return-Path: <lisa.dusseault@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 85ECE3A6A1E for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 13:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.384
X-Spam-Level:
X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.214, 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 hVPBmvQsproI for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 13:43:45 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 79FAB28C102 for <mmox@ietf.org>; Tue, 24 Feb 2009 13:43:45 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id l9so2483386rvb.49 for <mmox@ietf.org>; Tue, 24 Feb 2009 13:44:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VQojdDNI/kJORRK8ZLf1tqd+lTG9vshOE+NWEm0siC0=; b=q5T0B2wbvRcWshcrTdP7X8hsl0R6GVZCL6wUVY6qH9AwmLCucxtLZ9jIm30cNTYoqz FQZ9/IpbKsIRszVO4da9I+yE/PgHrJxpe3iWvpd7TgQMbPMurWitDEfYB8goUG9B2WtD /1SEehiktaJeu2N7VzZ+/zq3F1HVvULErHr2w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g4J37WcliFEhgkYAobHp9KAInCg2UovV/Dib5OuqaxokHoxtDNLIf3Ii8FFNun9DMA wPC7W72qtum1MVYgDtTInUyN4J4aiIlI/iGEJZNdo0jOIP0qz6dB0muXSfnSuF08OqDB MH8B05/6Jv4zAOzsNVjUPbFGAu4muZQTCdN8w=
MIME-Version: 1.0
Received: by 10.140.144.6 with SMTP id r6mr2782807rvd.185.1235511844250; Tue, 24 Feb 2009 13:44:04 -0800 (PST)
In-Reply-To: <ebe4d1860902240729x5e86306bpd0950b05c3a11f28@mail.gmail.com>
References: <ebe4d1860902240729x5e86306bpd0950b05c3a11f28@mail.gmail.com>
Date: Tue, 24 Feb 2009 13:44:04 -0800
Message-ID: <ca722a9e0902241344n5370ca87g2599e4799e16dfa5@mail.gmail.com>
From: Lisa Dusseault <lisa.dusseault@gmail.com>
To: Catherine Pfeffer <cathypfeffer@gmail.com>
Content-Type: multipart/alternative; boundary="000e0cd2296097a5a70463b1042d"
Cc: mmox@ietf.org
Subject: Re: [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 21:43:46 -0000

On Tue, Feb 24, 2009 at 7:29 AM, Catherine Pfeffer
<cathypfeffer@gmail.com>wrote:

> 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


This is something we (in IETF) have found to be a *drawback* in an
extensible standard.  We've hesitated over even providing DTDs in some
cases, worried that implementors would validate incoming messages against
the DTD, and drop messages that didn't validate, even ones that had been
extended according to a new standard.

The example I have the most familiarity with is WebDAV.  In a response to a
query to get the properties of a file in WebDAV, you might see:

     <D:response xmlns:R="http://ns.example.com/boxschema/" xmlns:D="DAV:">
         <D:href>http://www.example.com/file</D:href>
         <D:propstat>
           <D:prop>
             <R:bigboxtype>Box type A</R:bigboxtype>
             <R:author><R:Name>J.J. Johnson</R:Name></R:author>
           </D:prop>
           <D:status>HTTP/1.1 200 OK</D:status>
         </D:propstat>
    </D:response>

The specification says that anything inside the 'response' element should be
ignored if not understood, but if the 'href' element is there it contains
the file address and if the 'propstat' element is there it contains a number
of properties with the same status.  ...etc... Any element inside the 'prop'
element is a property name and inside that element is the property value.

Thus, the list of XML elements you would see inside the 'prop' element can
change for any resource or at any time and the recipient still knows what it
means.

This is reasonably concise (for XML which is not saying much) and extensible
as long as recipients follow the rules of ignoring unknown elements in some
places and treating them as property names in other places.  However, it is
NOT amenable to using DTDs, XML Schema or any form of restrictive
validation.

Someday, somebody could come up with a new metalanguage that does a better
job of this for XML.  RelaxNG is a step in that direction.  Because of the
separation between XML and the various description or schema languages that
work for XML, an argument against or for a description or schema language is
not the same thing as an argument for or against XML.

Lisa