OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml] Suggestions for a JSON representation of the XACML request - JSON profile


From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Danny Thorpe
Sent: Thursday, May 10, 2012 8:24 AM
To: David Brossard; xacml
Subject: RE: [xacml] Suggestions for a JSON representation of the XACML request - JSON profile

> Ideally, a JSON profile should be an isomorphic representation of the XACML spec, not a reinterpretation of the spec.


> Is there some convention in the JSON world by which we can associate a namespace with a JSON object, perhaps as a property?
> ("namespace": "urn:xacml:3.0:etc")?  

Not officially, but there are approaches to emulate this, e.g. http://elegantcode.com/2011/01/26/basic-javascript-part-8-namespaces/.
A property would work just as well.

However, we've now moved from talking about JSON, which is a format, to JavaScript, which is a programming language. There are other languages that may benefit from JSON over XML. Even in languages with good XML support one could prefer JSON, since it's less bytes over the wire.

> Unnamed objects: Shouldn't the unnamed objects in your example be contained in an array? 

Yes, they should.

> I think shortening the identifiers only needs to be done to make JSON property names compatible with JavaScript syntax 
> - there's no pressing need to shorten the values.  

I guess that depends on the goal(s) we're trying to achieve with this profile. One reason for preferring JSON over XML is that it's more compact.

> Define some constants in a JavaScript file that contain the XACML spec urns and instruct devs to compare against the 
> constants instead of using string literals. Defining the values as constants is a good idea anyway.


> Assuming default values for infrequently used items: hmm.  ok, as long as those values can be preserved in round trip transforms 
> to XML and back.  


> Since the XML spec generally avoids default values

Completely off topic, but I don't like that. For instance, when introducing new functionality, the default should be the old behavior (e.g. ReturnPolicyIdList="false"). This makes migration a lot less painful. The exception is when the old behavior is broken in some way (e.g. not secure).

For the current topic: if one of the goals for the JSON profile is to minimize network traffic, then assuming default values is a good way to do that.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]