DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=mime-version:date:message-id:subject:from:to:content-type;
 b=dW2zxdRmIi5lIosyzP/3M65Iv+X58ViM/JcmyIUNcW20G5EWgtFyOX1LHXctW3pKLW
 9o5LACRl5kRo9iO2CpR+Anm6V/9BTAwZR/rYYRy25An1Zrh3VSXynXEdwsOqrnwRmEvX
 xAvDpZzEeRX/HWq10g6RcqCaHWg9X4mgOk0OE=
MIME-Version: 1.0
Date: Tue, 24 Feb 2009 15:40:58 +0100
Message-ID: <ebe4d1860902240640u4e24ac2an5d4a2686286eb40e@mail.gmail.com>
From: Catherine Pfeffer <cathypfeffer@gmail.com>
To: mmox@ietf.org
Content-Type: multipart/alternative; boundary=0015174be96685136e0463ab1bfa
Subject: [mmox] xxSD working group?
Precedence: list

--0015174be96685136e0463ab1bfa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Infinity wrote:
> Catherine... Jon...
>
> can you create a proposal for a next generation XML serialization?

Yes I can.

> the existing serialization is in current use by SL, OpenSim and PyOGP,

Really? I am surprised to hear that, because I had once the curiosity to run
Wireshark to sniff packets exchanged by my Second Life client with the
simulators, and I saw that the binary serialization was used all the time,
even when using the new capacities system. Could you please point me to a
situation where I could test the existing XML serialization?

> so there's probably going to be a lot of resistance to changing
> something that currently works and is deployed.

Infinity, we need to make once for all clear whether this is just a Linden
Lab existing technologies rubber stamping work group, or if we are designing
vendor independent protocols for the 3 dimensional web of the future.

While I agree there is no reason to throw away existing stuff (like LLSD's
simplicity) when it is cool, I think that every bit of the technology should
be evaluated, and replaced when it has conceptual flaws in it.

If you disagree with this position, please state it clearly, and I would be
happy to withdraw from this mailing list and to go to other projects where I
might be more useful. Similarly, if Linden Lab's position is "let them speak
and then enforce our own stuff at the end", please also spare my time.

> keep in mind, however, that OGP does not use XML to represent it's
> PDUs, it uses LLSD. XML is one of three defined serializations of
> LLSD. it's a subtle difference, but important.

I have it in mind, even though the rationale for using three different
serializations is far from being clear to me.

> for instance... is there a benefit to explicitly adding support for
> namespaces to the XML serialization?

That's a very good question. What would be the purposes of such namespaces?

> there was a bit of discussion
> about this amongst some AWG members, and the consensus was... "why
> bother? the XML (presentation layer) is not the place where you want
> to extend the PDU... you want to extend it in the LLSD / LLIDL
> definition of the interaction."

Makes sense.

But this reasoning apparently assumes that the namespaces would be used to
extend the interoperability standard.

Normally, namespaces are rather used to mix data from different standards.

That could be *very useful* if we want to mix LLSD for example with a mesh
description expressed in another standard. Or to be able to include SVG
graphics. Etc. While this would be very powerful, that would not scale back
to the two other serializations, because it's pure XML mechanisms.

(That's not the only point where needing support for three serializations
has drawbacks. For example, LLIDL would become unnecessary if using only
XML, because the names and types of the fields could be stored in schema or
DTD fragments, or even in a WSDL dictionary. But never mind.)

> but, i still think it's an interesting idea as it might allow systems
> that use XML serialization exclusively to extend display and
> distribution options of various PDUs.


-- 
Cathy

--0015174be96685136e0463ab1bfa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Infinity wrote:<br>&gt; Catherine... Jon...<br>&gt;<br>&gt; can you create =
a proposal for a next generation XML serialization?<br><br>Yes I can.<br><b=
r>&gt; the existing serialization is in current use by SL, OpenSim and PyOG=
P,=C2=A0 <br>
<br>Really? I am surprised to hear that, because I had once the curiosity t=
o run Wireshark to sniff packets exchanged by my Second Life client with th=
e simulators, and I saw that the binary serialization was used all the time=
, even when using the new capacities system. Could you please point me to a=
 situation where I could test the existing XML serialization?<br>
<br>&gt; so there&#39;s probably going to be a lot of resistance to changin=
g =C2=A0<br>&gt; something that currently works and is deployed.<br><br>Inf=
inity, we need to make once for all clear whether this is just a Linden Lab=
 existing technologies rubber stamping work group, or if we are designing v=
endor independent protocols for the 3 dimensional web of the future.<br>
<br>While I agree there is no reason to throw away existing stuff (like LLS=
D&#39;s simplicity) when it is cool, I think that every bit of the technolo=
gy should be evaluated, and replaced when it has conceptual flaws in it.<br=
>
<br>If you disagree with this position, please state it clearly, and I woul=
d be happy to withdraw from this mailing list and to go to other projects w=
here I might be more useful. Similarly, if Linden Lab&#39;s position is &qu=
ot;let them speak and then enforce our own stuff at the end&quot;, please a=
lso spare my time.<br>
<br>&gt; keep in mind, however, that OGP does not use XML to represent it&#=
39;s =C2=A0<br>&gt; PDUs, it uses LLSD. XML is one of three defined seriali=
zations of =C2=A0<br>&gt; LLSD. it&#39;s a subtle difference, but important=
.<br><br>
I have it in mind, even though the rationale for using three different seri=
alizations is far from being clear to me.<br><br>&gt; for instance... is th=
ere a benefit to explicitly adding support for =C2=A0<br>&gt; namespaces to=
 the XML serialization?<br>
<br>That&#39;s a very good question. What would be the purposes of such nam=
espaces?<br><br>&gt; there was a bit of discussion =C2=A0<br>&gt; about thi=
s amongst some AWG members, and the consensus was... &quot;why =C2=A0<br>&g=
t; bother? the XML (presentation layer) is not the place where you want =C2=
=A0<br>
&gt; to extend the PDU... you want to extend it in the LLSD / LLIDL =C2=A0<=
br>&gt; definition of the interaction.&quot;<br><br>Makes sense.<br><br>But=
 this reasoning apparently assumes that the namespaces would be used to ext=
end the interoperability standard.<br>
<br>Normally, namespaces are rather used to mix data from different standar=
ds.<br><br>That could be *very useful* if we want to mix LLSD for example w=
ith a mesh description expressed in another standard. Or to be able to incl=
ude SVG graphics. Etc. While this would be very powerful, that would not sc=
ale back to the two other serializations, because it&#39;s pure XML mechani=
sms.<br>
<br>(That&#39;s not the only point where needing support for three serializ=
ations has drawbacks. For example, LLIDL would become unnecessary if using =
only XML, because the names and types of the fields could be stored in sche=
ma or DTD fragments, or even in a WSDL dictionary. But never mind.)<br>
<br>&gt; but, i still think it&#39;s an interesting idea as it might allow =
systems =C2=A0<br>&gt; that use XML serialization exclusively to extend dis=
play and =C2=A0<br>&gt; distribution options of various PDUs.<br><br><br>--=
 <br>Cathy<br>


--0015174be96685136e0463ab1bfa--