Re: JSON Profile WD-14 Issues

[Steven Legg <steven.legg@viewds.com>]

Hi David,

On 19/08/2013 5:37 PM, David Brossard wrote:
> Hi Steven,
>
> See my comments inline:
>
>
> On Mon, Aug 19, 2013 at 9:03 AM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote:
>
>
>     Hi David,
>
>     I noticed some problems in working draft 14 of the JSON profile.
>
>     Section 5.2.2 mentions "Attributes" as one of the objects in a Result
>     object (which you have now called Category") and section 5.2.9 uses
>     "object" to refer to both the XML element and its corresponding JSON
>     representation. You should refer to the <Attributes> *element* and
>     the Category *object*.
>
> I changed the phrasing to:
>
>   * Attributes: this object is optional. It can be single-valued or an array of Category
>     <file:///C:/Users/djob/Documents/research/OASIS/xacml-tc/JSON/xacml-json-http-v1.0-wd15.doc#_The_Category_object>
>     objects.

You're still referring to an Attributes object. It would be adequate to say:

    * Category: this object is optional. It can be single-valued or an array of Category.

Section 5.2.9 makes the connection between the Category object and the <Attributes> element.

To make the connection more explicit I would say something like this:

    * Category: an optional object or array of objects. A Category object is the
                JSON representation of an <Attributes> element.

Section 5.2.9 should read something like this (assuming it must still be
talking about an Attributes object too):

    Section 5.2.9 The Category object representation

    The JSON representation of an <Attributes> element in a XACML response is
    a Category object, as defined in section 4.2.2.


Of course, if you had stuck with Attributes as the name the terminological
awkwardness would evaporate.

> Category is now a link to the relevant section in the profile document.
>
>
>     Section 5.2.4 says "the StatusCode object may contain a sequence of
>     StatusCode objects". The XACML core says something similar, but the
>     associated XML Schema allows at most one child StatusCode element.
>     I've added an item on this to the wiki errata page. Assuming the XML
>     Schema is correct, a StatusCode object contains an optional
>     StatusCode object.
>
> Regarding this, I followed the PDF rather than the XSD. In the PDF, it is stated that:
>
>     /The <StatusCode> element contains a major status code value and an optional sequence of minor  status
>     codes./
>     /<xs:element name="StatusCode" type="xacml:StatusCodeType"/> /
>     /<xs:complexType name="StatusCodeType">/
>     /  <xs:sequence>/
>     /  <xs:element ref="xacml:StatusCode" minOccurs="0"/>/
>     /  </xs:sequence>/
>     /  <xs:attribute name="Value" type="xs:anyURI" use="required"/>/
>     /  </xs:complexType> /
>     /The <StatusCode> element is of StatusCodeType complex type. /
>     /The <StatusCode> element contains the following attributes and elements: /
>     /Value [Required] /
>     /See Section B.8 for a list of values. /
>     /<StatusCode> [Any Number] /
>     /Minor status code. This status code qualifies its parent status code./
>
> In that respect, the JSON profile is in line with the XACML 3.0 PDF standard and I would rather keep it that
> way.

Officially the text is normative, but I expect that changing the text is less
troublesome than changing the XML Schema, so I would like to get a sense of
how the TC will approach fixing this before deciding one way or the other.

>     Section 5.2.6 refers to the Advice object, but it should be referring
>     to the ObligationOrAdvice object.
>
> Yes, you are right. One of my developers actually emailed me that very point a week back. It's now fixed.
>
>
>     Regards,
>     Steven
>
>
>
> Thanks for spotting those. They are minor however and I don't want to disrupt the current process (unless
> the profile doesn't pass public review of course).
>
> What do you think?

I haven't seen an announcement so I assume there is an opportunity for
another revision.

Regards,
Steven

> --
> David Brossard, M.Eng, SCEA, CSTP
> Product Manager
> +46(0)760 25 85 75
> Axiomatics AB
> Skeppsbron 40
> S-111 30 Stockholm, Sweden
> http://www.linkedin.com/companies/536082
> http://www.axiomatics.com
> http://twitter.com/axiomatics