9 messages in org.oasis-open.lists.xacmlRE: [xacml] Suggestions for a JSON re...| From | Sent On | Attachments |
|---|---|---|
| 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 | |
|---|---|---|
| From: | remo...@emc.com (remo...@emc.com) | |
| Date: | May 10, 2012 6:09:13 am | |
| List: | org.oasis-open.lists.xacml | |
Danny,
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.
+1
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.
+1
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.
+1
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.
Thanks, Ray