OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: JSON Profile WD-14 Issues

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

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
    /<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

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.


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.


David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]