Re: [mmox] More LLIDL questions

[Mark Lentczner <[e-mail]>]

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]