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

[Morgaine <[e-mail]>]

Extensibility through XML is not extensibility of the types of the
underlying ADT.

The types of the ADT are expressed through 3 canonical serializations.
Those serializations merely reflect the types defined by the underlying ADT,
and the XML serialization alone cannot extend the underlying ADT without
breaking the mapping of the ADT to the other serializations.

It's the type system itself that has to be extensible before you can validly
use extended types in one of its serializations.


Morgaine.




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

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

> I considered LLSD format not just for legacy reasons, yet LL obviously used
> it because it is easier to document. It can be improved, yes, so I don't see
> the argument about it's extensibility of any merit. If the data can be
> traslated to XML, then we know we can further translate into other types or
> formats that work better. Usually that 'better' is something considered
> 'obvious' with RFCs, and that's where we 'obviously' don't have to update
> the RFC.
>
> There is enough reason to update the RFC for combined queries (and further
> denote such in LLIDL for pivotal data), yet seems like people have gone
> other routes, like SPDY, to accomplish the same basis in connection
> pipelines. I think the IDL needs to be in as format that others WGs besides
> VWRAP can use, and to denote the pivotal data only focuses more on the
> region-agent transistions. Realize that we are not all on the same scale as
> we work this, which is normal.
>
> I don't see why to update the RFC if it doesn't at least address that.
> Otherwise, I'm not against either LLSD or DSD. I do prefer the symbolic
> assembly equivalent before the plain english equivalent The symbolic
> equivalent tends to avoid use of reserved words in LLIDL.
>
> I think the extensibility of LLSD is moot given the XML translation is
> given. Anybody can further extend the XML data. For example, here is JSONx:
> https://datatracker.ietf.org/doc/draft-rsalz-jsonx . So, from XML to XML
> of those documents two are now trivial WIP.
>
>
> On 05/04/2011 05:24 AM, Morgaine wrote:
>
>> You're mixing up two very different questions, Meadhbh:� the first is
>> whether anyone is going to use DSD for something personally (in the way that
>> they have already used LLSD in the past), and the second is whether VWRAP
>> might adopt DSD for its type system.
>>
>> The answer to the first is clearly "*Yes*" because it's already been done
>> with LLSD in an ad hoc fashion.� However, it would be excellent if you were
>> to publish a proper RFC on DSD, and even better if you could provide an
>> actual library and bindings/API for it.� None of the current implementations
>> of LLSD went as far as creating separate and directly usable LLSD API
>> projects maintained by their creators, as the libomv and C++ implementations
>> are entangled within the very large codebases of their respective projects,
>> and the other implementations are poor quality and not maintained.� You
>> could do much better than they did, and keep a discrete DSD library afloat
>> and up to date.� That would ensure its survival.
>>
>> The answer to the second question is equally clearly "*No*", because IETF
>> working groups don't work through proposers' ultimatums.� A few weeks ago
>> there were significant questions raised here about whether LLSD/DSD is
>> adequate for a standard that is intended /for the future/ of VWs rather than
>> for implementing today's SL and Opensim-based software, so it's clear that
>> the issue hasn't been decided and requires more examination.
>>
>> Carlo put it (rather bluntly) here ---
>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00569.html .�
>> Without going into the politics of it, I want to see VWRAP have a properly
>> extensible type system, and the current LLSD does not meet that
>> requirement.� Indeed, in the early days of our IETF effort, we spent months
>> discussing the width of integers in LLSD because there was only *one width*
>> allowed and it was *hardwired* in the spec.� That's not an extensible
>> approach to data types at all.
>>
>> We need to do a lot better in this area if we really mean "extensible"
>> when we say "extensible".� At present that ADT proposal is not extensible in
>> any meaningful way.
>>
>>
>> Morgaine.
>>
>>
>>
>> ====================
>>
>> On Tue, May 3, 2011 at 3:19 PM, Meadhbh Hamrick <[e-mail]<mailto:
>> [e-mail]>> wrote:
>>
>>    is anyone in this group still interested in using LLSD (or it's
>>    successor, DSD)?
>>
>>    if so, i'm going to publish the DSD draft here. if not, i'm going to
>>    wait for the group to say "we are in no way interested in LLSD or DSD"
>>    and then submit it as an individual submission to the RFC editor. it's
>>    been about three years, and i would really like to get an RFC
>>    published so i can take the X- off all my application/llsd family of
>>    mime types.
>>
>>    so... may i see a show of hands... is anyone still planning on
>>    implementing a system with LLSD in this group?
>>
>>    please just respond yes or no in reply to this thread. i'll start
>>    another thread for discussion.
>>
>>    -cheers
>>    -meadhbh
>>    --
>>    meadhbh hamrick * it's pronounced "maeve"
>>    @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>>    <mailto:[e-mail]>
>>    _______________________________________________
>>    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
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>