[Openid-specs-ab] Language Script Tags

Justin Richer jricher at mitre.org
Thu Mar 14 18:41:22 UTC 2013


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



More information about the Openid-specs-ab mailing list