[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Providing JSON default values
On these default values in JSON… do we need to describe how that should work? As JSON objects, there’s no inherited behaviors so there’s no intrinsic way
to define the defaults in the JSON representation itself. Somebody has to provide the defaults for the JSON objects. This is less of a concern for PDP implementations since we’re expecting most implementations will be transforming the JSON representation into an internal object
format already used to represent the XML representation in memory. Default values can be provided by the internal objects’ existing default-on-demand mechanism for optional XML artifacts or can be injected by the transformer for mandatory XML artifacts. Client applications receiving JSON XACML decision responses, though, are less likely to be funneling JSON objects into an existing XACML object representation.
For many _javascript_ applications, the JSON objects *are* the XACML object representation. For these cases, the application will need a way to supply default values for artifacts that are elided from the JSON object representation. I’m assuming that the JSON objects would need to be composed with “actual” objects that provide default values for the consumer of the JSON objects – be that
the PDP (receiving a JSON request) or the client application (receiving a JSON response). Profile text something like this maybe? An implementation will need to perform some fashion of post-processing or composition to provide the default value semantics defined in this profile on JSON
objects, since JSON objects cannot provide default values themselves. For example, an application may implement wrapper classes which can express all the entities and attributes defined in this profile, and can be bound to JSON
object instances. When application code requests an attribute/property value using a wrapper class, the wrapper class can check to see if that attribute/property is defined in the bound JSON object. If it is defined in the JSON object, it returns the JSON
value(s). If it is not defined in the JSON object, the wrapper class can return the appropriate default value for that attribute/property. Alternatively, an application may instead traverse the JSON objects immediately after receipt and inject default values for
attributes/properties not present in the JSON object. This avoids the wrapper classes but uses more memory than a default-on-demand approach. -Danny Danny Thorpe
Product Architect |
|
Quest Software -
Now including the people and products of BiTKOO |
www.quest.com From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org]
On Behalf Of David Brossard Submitter's message
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]