Re: [mmox] More LLIDL questions

["Meadhbh Hamrick (Infinity)" <[e-mail]>]

good eye john.

yes, the purpose of the list is to provide an array of first_name,  
last_name pairs. however... yes... it is an improperly formed array.  
it was supposed to be

[ string ... ]

with the understanding that the array SHOULD contain an even number of  
entries, odd entries representing an avatar's first_name, even entries  
representing an avatars last_name.

-cheers
-meadhbh

On Feb 19, 2009, at 5:56 PM, Hurliman, John wrote:

> Great, thank you for the quick responses on all of these questions.  
> Keeping the implementation private is a good way to test the  
> accuracy of the draft and determine if it explains the concepts well  
> enough. For the most part it seems reasonable, but there are parts  
> that I've scratched my head at. Generating strongly typed classes in  
> C# from LLIDL leaves a lot of unnamed ("anonymous", in C#-speak)  
> variables.
>
> Last question. I found this snippet of LLIDL from the agent login  
> draft proposal on the Second Life wiki:
>
> agents: [ first_name: string, last_name: string ... ]
>
> Is that valid LLIDL, or should it be:
>
> agents: [ { first_name: string, last_name: string } ... ]
>
> Allowing key:value pairs in arrays seems to defeat the purpose of  
> the map type.
>
> John
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On  
>> Behalf Of
>> Mark Lentczner
>> Sent: Thursday, February 19, 2009 5:16 PM
>> To: [e-mail]
>> Subject: Re: [mmox] More LLIDL questions
>>
>> On Feb 18, 2009, at 12:39 PM, Hurliman, John wrote:
>>> ; An LLSD value containing { member1 : true, member2 : true } comes
>>> in. Is member3 a string or an int?
>>> &a = { member1 : true, member2 : false, member3 : string }
>>> &a = { member1 : false, member2 : true, member3 : int }
>>
>> In our LLIDL implementation, if you matched that LLSD against the
>> LLIDL value "&a", with those variants in scope, the answer would come
>> back INCOMPATIBLE.  This is because no variant matched the value.  In
>> the case of the selectors in LLIDL, they all need to match.
>>
>> Had the variants been:
>> &a = { member1: true, member3: string }
>> &a = { member2: true, member3: int }
>>
>> The answer would be MIXED.  This is because the actual value matched
>> each variant with the same result: In each case, the the data had
>> parts that were ADDITIONAL (member2 or member1), and parts that were
>> DEFAULTED (member3).  The state of having both DEFAULTED parts and
>> ADDITIONAL parts is MIXED. Matching variants returns the best match,
>> but in this case they were both MIXED, so the result is MIXED.
>>
>> Hope that was clear.
>>
>> Please note: The notion of returning a confidence level from a LLIDL
>> to actual LLSD match is a function of our library, not part of the
>> specification.  This was intentional: LLSD is defined in such a way
>> that given *any* LLSD, and code that expects any particular structure
>> - the code can safely extract values, receiving defaults if things
>> don't match as expected. Hence, LLIDL isn't a way of expressing a  
>> hard
>> "go/no-go" conformance, it is a way of expressing what is expected.
>>
>>> ; How is a parser supposed to handle this?
>>> &b = { $ : &b }
>>> ; Or this?
>>> &c = { $ : &d }
>>> &d = { $ : &c }
>>
>> We could declare recursive LLIDL is illegal.  It isn't too hard to
>> detect. On the other hand, since LLSD data values can't be recursive,
>> even if you have a recursive LLIDL description, any actual match
>> operation is bounded.  Our implementation handles recursive LLIDL and
>> it took no extra work to do so.
>>
>>> ; The first variant has the type uri. The second variant has the
>>> type string?
>>> &e = uri
>>> &e = "http://www.google.com/"
>>
>> The second doesn't have the type string, it is a selector of a
>> specific string.   Here's how our LLIDL would match these LLSDs:
>> 	string "http://www.google.com/" --> MATCHED (matches the selector
>> exactly)
>> 	string "http://www.example.com/" --> CONVERTED (convertable to a
>> uri)
>> 	uri "http://www.google.com/" --> MATCHED (matches the type uri)
>> 	uri "http://www.example.com/" --> MATCHED (matches the type uri)
>> 	string "" --> INCOMPATIBLE (neither matches the specific selector
>> string, nor is a reasonable conversion to uri)
>>
>> The notion of "reasonable conversion" is going to be implementation
>> specific, since LLSD defines a result no matter what is converted to
>> what.  In our case, we took the notion that if the transmitted value
>> only converts to the desired value via a defaulting, well, then, that
>> doesn't really increase the confidence in the match.  (There is some
>> subtlety in our choices here... I can go into it more if you like.)
>>
>>> ; Forward-slash seems like an odd addition to 0-9+A-Z. Why this
>>> character?
>>> &f/ = "hello slash"
>>
>> As a trailer, sure, but we like using slash as a name space delimiter
>> in our protocols for resource names, member names, fixed selector
>> strings, and, as you indicate, selector names:
>>
>> %% thing/operation_x
>> -> { id: uuid }
>> <- { name: string, system_a/count: int, system_b/count: int,  
>> system_c:
>> &system_c/info }
>>
>> &system_c/info = { name: string, count: int }
>> &system_c/info = { name: string, count: real, extended: true }
>>
>> 	- Mark
>>
>>
>> Mark Lentczner
>> Sr. Systems Architect
>> Technology Integration
>> Linden Lab
>>
>> [e-mail]
>>
>> Zero Linden
>> [e-mail]
>>
>>
>>
>>
>>
>> _______________________________________________
>> mmox mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmox
>>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox