[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Comments on JSON Profile 08
One more. The example in section 3.5 uses "value" instead of "Value". Regards, Steven On 7/12/2012 10:56 AM, Steven Legg wrote:
Hi David, Here are some issues I have noted in implementing the Working Draft 08 JSON profile (xacml-json-http-v1.0-wd08.doc). Section 3.4.1 - The shorthand type codes for data-types use inconsistent letter case for the first letter. We have "String", "Boolean", "Integer" "Double", "Time" and "Date" with a leading uppercase letter, but all the rest, e.g., "dateTime" and "anyURI", use a leading lowercase letter. I think they should all have a leading lowercase letter for consistency with the XACML data-type URI. Section 3.4.3 - The special numeric values NaN, INF and -INF need to be represented as JSON strings, i.e., "NaN", "INF" and "-INF". The data-type would have to be explicit when an XACML attribute value has one of these values. The special value -0 is okay as a JSON number. Since 4.2.5 expects the array of values to all be the same JSON construct (all string or all number), an attribute with double values would have to be represented as two separate attributes if it contains some regular values and some special numeric values. It would be easier if 4.2.5 allowed an array of string and/or number for the double data-type. Section 4.2.2.1 - RequestDefaults should be quoted and followed by a colon. Section 4.2.3.1 & 4.2.3.2 - The JSON representation allows only a single object for each of Subject, Action, Resource and Environment. An XACML request may have more than one Subject, Action, Resource or Environment, making them arrays rather than single objects. If there are multiple subjects, etc., then an implementation can always put them in the "Attributes" array, so I'm not fussed if you leave this the way it is. I'm just making the point in case it's something you hadn't considered. Section 4.2.5 - "Array of Boolean" should be added as a possible Type for the Value property. Section 4.2.5.1 - There should be a comma at the end of the line for "Id". Section 4.2.5 - This section says that Datatype defaults to string if omitted, but section 3.4.1 says the data-type can be omitted when it can be inferred from the value. I assume 4.2.5 is wrong and Datatype is to be inferred from the value(s) when it is omitted. For most of the XACML data-types the data-type can be inferred from the first value. However, the double data-type is the odd one out because an integer number is also a double value. Scanning an array of number to see if any number is a floating point number before deciding on the data-type would be inconvenient. Deciding on the data-type by looking at only the first value is easier. It needs to be stated which way the data-type is inferred so that JSON encoders know when they need to explicitly output Datatype for values of the XACML double data-type. On the last TC call I agreed to write up some text for a JSON encoding of values of the xpathExpression data-type. I will make this a separate email. Regards, Steven
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]