[Openid-specs-ab] Language Script Tags

Roland Hedberg roland.hedberg at adm.umu.se
Wed Mar 20 03:52:33 UTC 2013


+1

14 mar 2013 kl. 11:58 skrev Brian Campbell <bcampbell at pingidentity.com>:

> +1 to not screwing with it.
> 
> On Mar 14, 2013 2:55 PM, "Mike Jones" <Michael.Jones at microsoft.com> wrote:
> 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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-- Roland
------------------------------------------------------
Roland Hedberg
IT Architect/Senior Researcher
ICT Services and System Development (ITS) 
Umeå University 
SE-901 87 Umeå, Sweden	
Phone +46 90 786 68 44
Mobile +46 70 696 68 44 
www.its.umu.se 



More information about the Openid-specs-ab mailing list