Re: [vwrap] is the group still interested in LLSD or DSD?

[Morgaine <[e-mail]>]

On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <[e-mail]> wrote:

>
> XML is more than just serialization and mark-up language, yet this how
> people *start* with such concepts. It remains very useful for more advanced
> flows with absolute simplicity to the core to parse, and continues to be
> ridiculously easy to optimize, tokenize, and compress (with static
> dictionaries). Note that with static dictionaries, concerns like power
> consumption are already thought about because to even get that analytic
> computation done for each and every message only consumes more power.
>
>
This is what I can't seem to get across to you.  All those wonderful
features of XML are *IRRELEVANT* to the extensibility of the ADT's primitive
types, because the ADT defines its very limited set of abstract types
itself, directly.  The only thing that the ADT's serializations can do is
express those predefined ADT types on the wire.  You can't extend the
primitive types in a serialization of the ADT.

If you were arguing that our ADT's primary type definitions should be in XML
then you would have quite a good point, because then the types would be both
flexible and extensible.  But that's not what we're discussing here.


Morgaine.




==========================

On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <[e-mail]> wrote:

> On 05/04/2011 10:22 AM, Morgaine wrote:
>
>> Let me rephrase it more precisely.� Your responses do not *demonstrate*
>> understanding of the type model of LLSD + serializations.� You persist in
>> suggesting that the extensibility of XML can extend the elementary types of
>> LLSD, when it absolutely cannot do that.� I am confident that you do
>> understand this, but it hasn't come across yet.
>>
>> I recommend leaving XML out of the discussion, because it's just one out
>> of 3 primary serializations.� Leaving it out (for now) will help highlight
>> the non-extensibility of the LLSD elementary data types.
>>
>
> XML is only a more graphic form than ASCII and extended with common
> multi-byte format useful to detect network order. Because it is
> human-readable, many miss *that* obvious critical fact. If you send XML
> data, we don't have to worry about the network order for whatever abstract
> data types you make up.
>
> XML is more than just serialization and mark-up language, yet this how
> people *start* with such concepts. It remains very useful for more advanced
> flows with absolute simplicity to the core to parse, and continues to be
> ridiculously easy to optimize, tokenize, and compress (with static
> dictionaries). Note that with static dictionaries, concerns like power
> consumption are already thought about because to even get that analytic
> computation done for each and every message only consumes more power.
>
> You're telling us you want to leave that already well-thought-critical
> details out of the discussion when it is already standardized and already
> just easily said as "XML"?
>
> We realize that some implementers made LLSD mean "Linden Lab Serialized
> Data", and they wanted JSON instead because it *was* easily to eval() to
> parse. (Except now JSON has to avoid injections just like SQL & perl/php,
> etc, ...).
>
> I'm pretty sure the real problem has been DEMONSTRATED with the
> implementation(s), especially where you further demonstrated that you want
> to leave out any mention of the extensibility features in order to show the
> problem with non-extensibility. That sounds familiar.
>
>
>
>  It's a really fundamental aspect of the ADT that it defines our types
>> independent of its serializations. �It's a useful concept, but the problem
>> with this particular one -- LLSD (DSD?) -- is that the elementary types are
>> neither flexible nor extensible.
>>
>>
> Let the VMs define further ADTs. We only need a few standard data types.
> This WG should only be concerned with being able to document (and clarify)
> the flow, especially the region-agent transistions. If the flow uses
> standard LLSD data types to define some complex abstract data type, perfect
> enough. I wouldn't be surprised if we add one more LLSD data type for DAEs,
> as that may be the perfect place for it. Then you can go and add any
> relevant extension you want to the DAE, even more abstract data types within
> the DAE, and further you don't even have to worry about it all being in RFC
> format.
>
>
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>