Re: [mmox] More LLIDL questions

["Hurliman, John" <[e-mail]>]

Ah, that would work too. In fact, my reading of the draft says that

[ string, string ... ]

Would accomplish exactly that.

>-----Original Message-----
>From: Meadhbh Hamrick (Infinity) [mailto:[e-mail]]
>Sent: Thursday, February 19, 2009 8:23 PM
>To: Hurliman, John
>Cc: [e-mail]
>Subject: Re: [mmox] More LLIDL questions
>
>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

>