DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=mime-version:date:message-id:subject:from:to:content-type;
 b=bD/+C0IbIDKGpmyU2vlzUr0nzTa6L9z8dBmIwifVoBaixh+2/Qew0ql0C3j7YVtRX/
 hafYQAYYJBhfsXmRARRo0fKy0OquSu3Y2zybEmbdldUABpjCYF6K5vpfdoXV/Hc43fpB
 X428XwXTLaL84WVks4Q4X/5HWq7z9Qxj5jcbo=
MIME-Version: 1.0
Date: Tue, 24 Feb 2009 20:04:37 +0100
Message-ID: <ebe4d1860902241104k2761c55pd5b62358ce5c631c@mail.gmail.com>
From: Catherine Pfeffer <cathypfeffer@gmail.com>
To: mmox@ietf.org
Content-Type: multipart/alternative; boundary=0015174c1a685cb9fb0463aeca85
Subject: [mmox] Formalizing my proposal
Precedence: list

--0015174c1a685cb9fb0463aeca85
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Infinity wrote:
> 1. can you please submit your proposal?

Sure. I'll submit a proposal that makes the XML serialization better,
although it would assume:
1)- that LLSD is what we need for lower layer
2) that we would stick to three serializations for LLSD and not just one,
leading to clumsy XML

both points are still not certainties in my mind. But I'll send the
formalized proposal as you asked it.

> most of the XML LLSD is sent over HTTPS,
> which might explain why you can't see it in wireshark

Aaah, Ok, thanks for the tip! ;-)

> 6. the reason we separate the serialization from the protocol
> definition is we want to avoid having to add "binary serialization",
> "json serialization" and "xml serialization" sections to each defined
> protocol interaction.

Yes, and that leads to a XML serialization that does not take all the
advantage of what can be done in XML, and that takes a lot of bandwidth.

Again, why would we need three serializations when one is just enough? Not
saying that it's just 1/3rd of the implementation effort...

> I think there's a history of people defining protocols
> using relatively "high level" abstractions, then providing mechanistic
> technique for generating the "octets over the wire."

That's correct, it's nice to think in abstract terms, and then map the
result to a given implementation. That does not mean you need three
implementations...

> 7. i really like the idea of using LLSD to represent meshes, link-sets
> of prims, or even 2d SVG representations of avatars and objects.

... which means, in XML, that we could not re-use existing meshes or SVG XML
dialects just by changing the namespace, but that we would have to "convert"
everything to LLSD.

While this would certainly work, it sounds to me like a lot of efforts,
while simply mixing
        vw:
and
        svg:
namespaces in one single file could do the trick. Otherwise, you'd first
have to define how SVG remaps to LLSD, then implement it.

XML namespaces are precisely offering this ability to mix different type of
data from different standards without ambiguity and without any need to
remap one standard into the other.


-- 
Cathy

--0015174c1a685cb9fb0463aeca85
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Infinity wrote:<br>&gt; 1. can you please submit your proposal?<br><br>Sure=
. I&#39;ll submit a proposal that makes the XML serialization better, altho=
ugh it would assume:<br>1)- that LLSD is what we need for lower layer<br>
2) that we would stick to three serializations for LLSD and not just one, l=
eading to clumsy XML<br><br>both points are still not certainties in my min=
d. But I&#39;ll send the formalized proposal as you asked it.<br><br>&gt; m=
ost of the XML LLSD is sent over HTTPS, =C2=A0<br>
&gt; which might explain why you can&#39;t see it in wireshark<br clear=3D"=
all"><br>Aaah, Ok, thanks for the tip! ;-)<br><br>&gt; 6. the reason we sep=
arate the serialization from the protocol =C2=A0<br>&gt; definition is we w=
ant to avoid having to add &quot;binary serialization&quot;, =C2=A0<br>
&gt; &quot;json serialization&quot; and &quot;xml serialization&quot; secti=
ons to each defined =C2=A0<br>&gt; protocol interaction.<br><br>Yes, and th=
at leads to a XML serialization that does not take all the advantage of wha=
t can be done in XML, and that takes a lot of bandwidth.<br>
<br>Again, why would we need three serializations when one is just enough? =
Not saying that it&#39;s just 1/3rd of the implementation effort...<br><br>=
&gt; I think there&#39;s a history of people defining protocols =C2=A0<br>&=
gt; using relatively &quot;high level&quot; abstractions, then providing me=
chanistic =C2=A0<br>
&gt; technique for generating the &quot;octets over the wire.&quot; <br><br=
>That&#39;s correct, it&#39;s nice to think in abstract terms, and then map=
 the result to a given implementation. That does not mean you need three im=
plementations...<br>
<br>&gt; 7. i really like the idea of using LLSD to represent meshes, link-=
sets =C2=A0<br>&gt; of prims, or even 2d SVG representations of avatars and=
 objects.<br><br>... which means, in XML, that we could not re-use existing=
 meshes or SVG XML dialects just by changing the namespace, but that we wou=
ld have to &quot;convert&quot; everything to LLSD.<br>
<br>While this would certainly work, it sounds to me like a lot of efforts,=
 while simply mixing<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vw:<br>a=
nd<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 svg:<br>namespaces in one =
single file could do the trick. Otherwise, you&#39;d first have to define h=
ow SVG remaps to LLSD, then implement it.<br>
<br>XML namespaces are precisely offering this ability to mix different typ=
e of data from different standards without ambiguity and without any need t=
o remap one standard into the other.<br><br><br>-- <br>Cathy<br>

--0015174c1a685cb9fb0463aeca85--