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

[Dzonatas Sol <[e-mail]>]

I would like to add the "stream buffer" data type, with optional 
metadata to normalize access to higher-levels, and with intent of 
content extraction/replacement by element tag (like XPath). This would 
make it so much easier to implement asset servers and agent services. 
(Yet, I rather have more implementation first than simple Schroedinger's 
cat idealogy to base RFC submission).

Do you want to update the text below to add your "ADT" to the already 
implemented type system?

In WIP: http://tools.ietf.org/html/draft-ietf-vwrap-type-system-00
Section 2:

    The LLSD abstract type system describes the semantics of data passed
    between two network hosts.  These types characterize the data when
    serialized for transport, when stored in memory, and when accessed by
    applications.

    The types are designed to be common enough that native types in
    existing serializations and programming languages will be usable
    directly.  It is anticipated that LLSD data may be serialized in
    systems with fewer types or stored in native programming language
    structures with less precise types, and still interoperate in a
    predictable, reliable manner.  To support this, conversions are
    defined to govern how data received or stored as one type may be read
    as another.

    For example, if an application expects to read an LLSD value as an
    Integer, but the serialization used to transport the value only
    supported Reals, then a conversion governs how the application will
    see the transported value.  Another case would be where an
    application wants to read an LLSD value as a URL, but the programing
    language only supports String as a data type.  Again, there is a
    defined conversion for this case.

    The intention is that applications will interact with LLSD data via
    interfaces in terms of these types, even if the underlying language
    or transports do not directly support them, while retaining as much
    direct compatibility with those native types as possible.

    An LLSD value is either a simple datum or a composite structure.  A
    simple data value can have one of nine simple types: Undefined,
    Boolean, Integer, Real, String, UUID, Date, URI or Binary.  Composite
    structures can be either of the types Array or Map.



On 05/04/2011 11:26 AM, Morgaine wrote:
> On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <[e-mail] 
> <mailto:[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] 
> <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/vwrap
>
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>    


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