Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4359E0686 for ; Wed, 4 May 2011 09:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO8rZA+sZom3 for ; Wed, 4 May 2011 09:06:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAF41E0684 for ; Wed, 4 May 2011 09:06:37 -0700 (PDT) Received: by qwc23 with SMTP id 23so1007749qwc.31 for ; Wed, 04 May 2011 09:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zZCi//pH0utsdHbsU5qqjzeTWZh56UiNPZh9A4Fv8Qs=; b=awoc0JNAp2sVgaFsQqbJcTNs9RntcCQ5josZKu5KLXZNq1/3fCuRc2ovSBS97uDyga lYZiwhrotZccyDRJ3zJ8vQmEns6mQQePjwKxvQk/kYCB15mQJLNaP/dk+2xQyJPYIpO3 h5oRSIbE44akwjhrCNtRiHOGMUppTs1VVvOfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DhRZCZH30rB46aa3eEsxuQFTrw9FQO5mWSFWZNsNo545JKwASkDrAiZmnnhBUz7yOo KE1zXDZWY6uvIwyDVqblT6QsfaenwoKOQW/gh9OmCqMk3qMBMitLrvpm9YpI4VJUEWzo aRJYcUcFMBri3FX2PkK++Nq7KkjOJpml6Y+cY= MIME-Version: 1.0 Received: by 10.229.44.141 with SMTP id a13mr928883qcf.101.1304525196666; Wed, 04 May 2011 09:06:36 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Wed, 4 May 2011 09:06:36 -0700 (PDT) In-Reply-To: <4DC17704.3020201@gmail.com> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> Date: Wed, 4 May 2011 17:06:36 +0100 Message-ID: From: Morgaine To: Dzonatas Sol Content-Type: multipart/alternative; boundary=001636831fa0f2b0f104a27570f7 Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 16:06:38 -0000 --001636831fa0f2b0f104a27570f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I gather that you don't understand the type model of LLSD + serializations then. The ADT defines the elementary data types and composite resource types. Th= e serializations then implement both of these for transport on-the-wire. There is nothing that one specific serialization like XML can do to to extend the elementary data types provided by the ADT. Your answers simply don't address the non-extensibility and non-flexibility of elementary types. The XML tail cannot wag the ADT dog. The relationshi= p is the other way around, it's the ADT that defines the elementary types, which are transported in all serializations. You keep referring to the flexibility of XML, but that is irrelevant to the ADT. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Wed, May 4, 2011 at 4:55 PM, Dzonatas Sol wrote: > It doesn't block "evolution of transported elementary types", as the > transport layer is underneath the application layer. As demonstrated (and > proven) with flow in XML, we can easily keep the high-level types in the > higher layer. LLSD is merely the high-level types, not overall primitives= . > > > On 05/04/2011 08:49 AM, Morgaine wrote: > >> That's a far clearer question than you asked initially, and so its easie= r >> to give a specific answer.=EF=BF=BD (Indeed, I already did before, in th= e second >> part of my response.) >> >> While I don't know exactly what DSD is (an RFC would be excellent!), if >> it's just LLSD with another name then the type system of its underlying = ADT >> is not extensible, and therefore it won't support new types going forwar= d >> into the future.=EF=BF=BD From my perspective, a non-extensible type sys= tem is *not >> sufficient* for VWRAP because it blocks the evolution of transported >> elementary types. >> >> And LLSD is actually worse than merely non-extensible, because it isn't >> flexible either, especially in providing just a single integer type.=EF= =BF=BD That's >> not enough. >> >> We need to design for tomorrow, not just for today. >> >> >> Morgaine. >> > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --001636831fa0f2b0f104a27570f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I gather that you don't understand the type model of LLSD + serializati= ons then.

The ADT defines the elementary data types and composite re= source types.=C2=A0 The serializations then implement both of these for tra= nsport on-the-wire.=C2=A0 There is nothing that one specific serialization = like XML can do to to extend the elementary data types provided by the ADT.=

Your answers simply don't address the non-extensibility and non-fle= xibility of elementary types.=C2=A0 The XML tail cannot wag the ADT dog.=C2= =A0 The relationship is the other way around, it's the ADT that defines= the elementary types, which are transported in all serializations.

You keep referring to the flexibility of XML, but that is irrelevant to= the ADT.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, Ma= y 4, 2011 at 4:55 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
It doesn't bl= ock "evolution of transported elementary types", as the transport= layer is underneath the application layer. As demonstrated (and proven) wi= th flow in XML, we can easily keep the high-level types in the higher layer= . LLSD is merely the high-level types, not overall primitives.


On 05/04/2011 08:49 AM, Morgaine wrote:
That's a far clearer question than you asked initially, and so its easi= er to give a specific answer.=EF=BF=BD (Indeed, I already did before, in th= e second part of my response.)

While I don't know exactly what DSD is (an RFC would be excellent!), if= it's just LLSD with another name then the type system of its underlyin= g ADT is not extensible, and therefore it won't support new types going= forward into the future.=EF=BF=BD From my perspective, a non-extensible ty= pe system is *not sufficient* for VWRAP because it blocks the evolution of = transported elementary types.

And LLSD is actually worse than merely non-extensible, because it isn't= flexible either, especially in providing just a single integer type.=EF=BF= =BD That's not enough.

We need to design for tomorrow, not just for today.


Morgaine.

--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


--001636831fa0f2b0f104a27570f7--