[Openid-specs-ab] Language Script Tags

Mike Jones Michael.Jones at microsoft.com
Thu Mar 14 18:54:54 UTC 2013


Let's not screw with the language tag syntax.  Every language has a way to access all JSON object members, even if it may not be the convenient shorthand method that's used for some fields.  I'd rather have programmers use the general-purpose syntax than make the identifiers less understandable.

				-- Mike

-----Original Message-----
From: Nat Sakimura [mailto:sakimura at gmail.com] 
Sent: Thursday, March 14, 2013 11:52 AM
To: Justin Richer
Cc: Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Language Script Tags

Yeah.

Using '_' instead of '#' however means that you will not be able to use '_' in the name, which we use a lot in the current claim syntax.
We could use '$' but that does not alone solve the problem since even '-' cannot be used in the name in Javascript.
So, object syntax is kind of screwed if we wanted to use BCP47 language tags.

To make it work in Javascript object syntax, we have to at least do the following:

Decide to use converted BCP47 string: s/-/_/g Use '$' as the delimiter.

Nat

2013/3/15 Justin Richer <jricher at mitre.org>:
> Yes, that's the array-style syntax, which works in many languages as well.
> What I was curious about was the object-style syntax, which works for 
> every other field that doesn't have the # symbol in it.
>
> An alternate syntax would be to just use something other than the # 
> symbol to separate the language script tags. "_" would be safest for 
> most languages, I believe.
>
> But if the answer is that most people are treating their parsed 
> elements like arrays instead of objects, then we might want to have 
> text in the section of messages that defines the hash-based syntax 
> stating the possible issue so that it doesn't surprise others down the 
> road. I'm not sure how to do that without going programming-language-specific though.
>
>  -- Justin
>
>
> On 03/14/2013 02:34 PM, Mike Jones wrote:
>>
>> If you parse the JSON as follows:
>>
>>         var j = JSON.parse(json);
>>
>> then I believe that in JavaScript, you can access the "client_name#en-us"
>> field using the syntax:
>>
>>         j["client_name#en-us"]
>>
>>                                 -- Mike
>>
>> -----Original Message-----
>> From: openid-specs-ab-bounces at lists.openid.net
>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat 
>> Sakimura
>> Sent: Thursday, March 14, 2013 11:29 AM
>> To: Justin Richer
>> Cc: openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] Language Script Tags
>>
>> I have been parsing it to associative arrays in PHP.
>>
>> Do you have alternative syntax proposal?
>>
>> Nat
>>
>> 2013/3/15 Justin Richer <jricher at mitre.org>:
>>>
>>> In implementing things, I've run into a problem when looking to 
>>> parse values with the language script tags and I'm wondering what 
>>> other developers have done.
>>>
>>> Specifically, the hash tag (#) is not a valid member name in 
>>> JavaScript, Python, PHP, or Java (and likely many others), which 
>>> means I can't do a simple JSON-to-Object deserialization on any 
>>> fields that use this construct.
>>> In other words, say I've got this JSON:
>>>
>>>    { "client_name#en-us": "Test Client" }
>>>
>>> Parsing that to JavaScript, I'd expect to be able to use the object 
>>> accessor, like:
>>>
>>>    client.client_name#en-us
>>>
>>> But that's not valid JavaScript. Yes, I can use array accessor 
>>> notation, but it's inconsistent with other fields. Similarly in 
>>> Java, I'd get something like this in a blindly-mapped object:
>>>
>>>    client.getClient_name#en-us()
>>>
>>> but that is also not a valid Java method name. It's the same basic 
>>> story on just about every language I've poked at in the last few 
>>> minutes here, so I can't be the first one to have run into this. 
>>> What has everyone else done to overcome this limitation in the 
>>> common parse/map operation? Do you have custom parsers that map the 
>>> field names? Do you just not use object-level accessors for these fields?
>>>
>>>   -- Justin
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


More information about the Openid-specs-ab mailing list