Re: [mmox] More LLIDL questions

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

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
>