[Openid-specs-fapi] Representing international strings

[Edmund Jay]

Actually, Swagger does allow # in the variable name. You just need to double quote the variable name.The bigger problem is that Swagger does not support the patternProperties that is defined as part of the JSON schema. patternProperties will allow us to specify something like name(#..)*Without patternProperties support, we might end up having to write the property names for each language/script.
As for using the map, it would be something like the following :
  ErrorMessage:    properties:      longMessage:        type: string      shortMessage:        type: string    MultilingualErrorMessage:    additionalProperties:    $ref: "#/definitions/ErrorMessage"      Error:    required:      - code      - message    properties:      code:        type: string      message:
        $ref: "#/definitions/MultilingualErrorMessage"    

Error is a multi-lingual error object like :
{"code": "dberror","message" : {
    "en" : {        "longMessage" : "long error message",
        "shortMessage" : "short error message",
    },    "fr" : {        "longMessage" : "some long message in French",
        "shortMessage" : "some short message in French"
    }}

The additionalProperties of MultilingualErrorMessage only state that it has additional properties that are ErrorMessage objects. It doesn't state what the property name is so it can be anything. But we would need to document that the property name must be language_script format or something like that.
The Swagger editor doesn't show additonalProperties in an obvious way.

      From: Nat Sakimura <nat at sakimura.org>
 To: Openid-specs Fapi <openid-specs-fapi at lists.openid.net> 
 Sent: Wednesday, July 13, 2016 10:54 PM
 Subject: [Openid-specs-fapi] Representing international strings
   
HiOpenID Connect introduced a variable name scheme for international scripts. For example, a name in Katakana script in Japanese will be represented as         name#ja-Kana-JPwhere "ja-Kana-JP" part is described in ISO script format. My question to the list is whether do we want to continue using this scheme even on Swagger. As swagger cannot have # in the variable name, it would become like        name%23ja-Kana-JPetc. This may be OK, but there could be better ways as well, I suppose. Another obvious ways to deal with it is to use map where the key is going to be the script name and value is the actual value for the parameter. In any case, I need to find out how to put a variable as the key/name in Swagger definition. Those who knows Swagger well, please help. Another issue that I have in mind is that what happens if Kanji arrives as "Name" in DDA endpoint. Would the application be OK with it or blows up? Read only case would probably be ok, but if you wanted to send money, for example, and there are Kanji in the Transfer message, what would happen to the US banking system? Do we need to mandate the current Name like string restricted to ASCII? Best, Nat Sakimura   
_______________________________________________
Openid-specs-fapi mailing list
Openid-specs-fapi at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-fapi


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20160714/ea7a6e6c/attachment.html>