Re: [mmox] Formalizing my proposal

[Lisa Dusseault <[e-mail]>]

I completely agree with this.  We'd need a pretty good reason to standardize
three serializations of the same data up front.  We'd also need a careful
model for who needs to support all, and who can choose which to support, and
how negotiation is done.  It's all a *lot* more standards work and
multiplies risks of interop failures.

That said, there is certainly good engineering behind having the layering
abstractions, and in some cases multiple serializations are worthwhile.
After 10 years of being in its own format, there's some effort to do an XML
version of iCalendar for inviting people to meetings.  The problem is no
negotiation support in the tools that use iCalendar.

Lisa

On Tue, Feb 24, 2009 at 11:04 AM, Catherine Pfeffer
<[e-mail]>wrote:

> 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
>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>
>