|David Brossard||May 9, 2012 6:19 pm|
|Danny Thorpe||May 9, 2012 11:22 pm|
|remo...@emc.com||May 10, 2012 6:09 am|
|remo...@emc.com||May 10, 2012 6:12 am|
|remo...@emc.com||May 10, 2012 6:15 am|
|David Brossard||May 17, 2012 5:56 am|
|Hal Lockhart||May 17, 2012 8:21 am|
|remo...@emc.com||May 17, 2012 1:50 pm|
|Anil Saldhana||May 31, 2012 10:56 am|
|Subject:||RE: [xacml] Suggestions for a JSON representation of the XACML request - JSON profile|
|Date:||May 10, 2012 6:09:13 am|
From: xac...@lists.oasis-open.org [mailto:xac...@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.
However, we've now moved from talking about JSON, which is a format, to
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
Yes, they should.
I think shortening the identifiers only needs to be done to make JSON property
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.
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.