Re: [ogpx] VWRAP still alive?

[Lawson English <[e-mail]>]

It strikes me that LLSD might be extended for specific issues beyond 
what it was originally intended for. E.G.

 http://ligwww.epfl.ch/%7Eaguye/AML/AMLOverview.pdf

within each specialized context, perhaps there can be default values 
assumed without the requirement of some kind of dtd or perhaps a 4/8 
character, DTD type might be made part of some future extension ala 
Apple's old type/creator codes.


Lawson







Meadhbh Hamrick wrote:
> yes, VWRAP _is_ still alive.
>
> we're currently working on three documents: LLSD / LLIDL, Intro and
> Requirements, and Assets
>
> * LLSD / LLIDL
>
> LLIDL was in the middle of getting a well deserved face lift when
> multiple, conflicting changes forced us to return to agreeing on the
> problem definition instead of pushing out a draft. LLIDL / LLSD draft
> development has been being informed by several pairwise / intense
> descussions involving investigation of specific use cases. i hope to
> get a wiki page up describing proposed changes at the end of this
> week.
>
> but essentially what we're looking at is thus:
>
> - peeps didn't grok why LLSD has the "you get the default value when
> you read a map key that's not there" semantics, so i'm integrating the
> "structure and interpretation of LLSD messages" email into the draft
> as motivation for why LLSD is needed. (
> http://www.ietf.org/mail-archive/web/mmox/current/msg00679.html )
>
> - peeps thought the LLIDL syntax was odd, that it didn't look "Cish
> enough." i'm developing a proposal for making LLIDL look more like an
> ALGOL derived language so C/C++/C#/Java programmers can look at it and
> have a more immediate understanding of what it's doing.
>
> - we want to be able to support GETs as well as POSTs when LLSD is
> carried over HTTP(S). this is so we an make use of intermediaries like
> caching squid servers. so we're working on a way to map a resource
> definition to a GET instead of a POST. i know there are some people
> who want to carry LLSD over XMPP, so we're interested in avoiding
> simply saying... "oh... just make this kind of message a GET" since
> that's more of a HTTP(S) specific construction.
>
> - related to the item above, we're looking at ways to encode a request
> as a query string. the idea here being that since some caching
> intermediaries can cache two GET requests with the same URL, including
> the query string, we want to be able to encode the request in the
> query string to take advantage of the caching behavior.
>
> - some people thought that the variant syntax was confusing.
> specifically, the relationship  between a variant record and the
> selector. (the selector is the element _in_ the variant map
> declaration that has a literal value.) in other words, the way the
> LLIDL parser knows that a particular variant is "valid" is that one of
> the members of the map has a specific value. the relationship to the
> variant and the selector was considered "haphazard" by some reviewers.
>
> - explaining the use of "late keys." i.e. - the '$' in some LLIDL
> definitions. the use of the dollar sign ('$') in LLIDL as the key of a
> map declaration indicates that there'll be a number of keys, the
> symbol for each is determined at message send time, not at resource
> definition time.
>
> - fixing things like broken XML DTDs.
>
> - changing the comment character from a semi-colon (';') to a hash mark ('#')
>
> * Intro and Goals
>
> There was a lot of commentary on the original "intro and requirements"
> doc in Stockholm, and a trickle of interest since then. There are a
> few minor changes to the draft, and the inclusion of a much better
> glossary. David is writing a section on deployment patterns, and we
> plan to integrate our changes "any day now."
>
> * Assets
>
> The Assets draft is in a much more "complicated" state. We're
> coordinating our efforts with John Hurliman who's the lead developer
> on the Cable Beach project. We hope that what will emerge will be a
> unified protocol for accessing second life resources as cable beach
> resources.
>
> -cheers
> -meadhbh
>
> On Sun, Nov 29, 2009 at 5:42 AM, Vaughn Deluca <[e-mail]> wrote:
>   
>> It has gotten terribly silent on the list, and its not hard to see why;
>> without updates of the drafts the discussion floats free and people are
>> bound to loose interest.
>> I  do understand that drafting these types of documents takes time, and too
>> much discussion in an early stage sometimes only complicates matters, yet, a
>> quick status update and maybe even a working version of the drafts in their
>> current form would be nice to keep everybody synchronised...
>> -Vaughn
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
>>     
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>