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] | [Elist Home]

Subject: [xacml] Errata errata

Thanks, Simon, for the concise and readable errata list!  This is
very helpful.  And thanks too, to Satoshi, who has picked up a
number of inconsistencies our tired eyes would never have noticed
at this point!

Following are my comments on both the errata list (attached to
and on the updated spec (in the same e-mail) that incorporated

Typographical Errors.

Reported by: Satoshi Hada
Message: http://lists.oasis-open.org/archives/xacml-comment/200212/msg00061.html
Description: On lines 3408 and 3413 DataType attribute is
Options: Replace DataType attribute value with

  Anne: I agree with the Options, but the implementation of them
  in the updated spec does not seem right: Line 3413 in the
  updated spec seems OK, but line 3408 now has "xs:string" rather
  than the correct value

Reported by: Satoshi Hada
Message: http://lists.oasis-open.org/archives/xacml-comment/200301/msg00007.html
Description: Incorrect data type URI in section B.4, lines 4438, 4439
Options: Change "2002/08/xquery-functions" to "TR/xquery-operators".

  Anne: We can't refer to
  "http://www.w3.org/TR/xquery-operators/"; because that points to
  the most recent Working Draft, and so changes under us.

  I think the correct reference is
  since it was that snapshot of the Working Draft that we defined
  our operators and types against.  Someone check me on this,

  This should be made consistent throughout the document,
  including in the References section.

Reported by: Satoshi Hada
Message: http://lists.oasis-open.org/archives/xacml-comment/200301/msg00018.html
Description: At the end of C.1, C.2, and C.3, we have the
  following description just after the explanation about
  policy combining algorithms: "Obligations of the individual
  policies shall be combined as described in Section".
  However, Section is about a policy rather than a set of
  policies.  So it should be Section rather than
Options: Update section references.

  Anne: Section does not describe how to combine
  obligations.  I recommend the section reference be to Section
  7.11 Obligations, where combining obligations is discussed.
  Tim, note that both and 7.11 are titled "Obligations",
  so your reference may be picking up one rather than the
  intended other.

Reported by: Satoshi Hada
Message: http://lists.oasis-open.org/archives/xacml-comment/200301/msg00019.html
Description: line 4314: [XF] section reference is incorrect
Options: Replace reference with 6.3.15

  Anne: I agree that the [XF] section reference is incorrect, and
  should be 6.3.15.  Note that this change MUST be made in
  conjunction with the "unchange" I recommend for
  (two errata above): there is no Section 6.3.15 in the current
  draft to which http://www.w3.org/TR/xquery-operators/ points!

Reported by: Satoshi Hada
Message: http://lists.oasis-open.org/archives/xacml-comment/200301/msg00034.html
Description: Section 5.28 says that: The
  SubjectAttributeDesignatorType extends the match semantics of
  the AttributeDesignatorType such that it narrows the attribute
  search space to the specific categorized subject such that the
  value of this element's SubjectCategory attribute matches, by
  string-equality, the value of the <Request> element's subject
  category attribute.

  I think "by string-equality" should be "by URI-equality"
  because the data type of the SubjectCategory attribute is "xs:anyURI".

  Anne: Use of "string-equality" was intentional.  Once we
  eliminated QNames, we made it possible for the SubjectCategory
  attribute values to be compared as strings.  We chose to
  specify it that way since "string-equality" is simpler than

  We could always change our minds, but this was intended at the

Final erratum on Obligations.

  Anne: This is clearly new functionality.  I agree that
  Obligations is underspecified, but I don't think we can make
  these fixes without changing the document in non-trivial ways.

  I recommend that IBM present us with a proposal for how Section
  7.11 should be augmented to cover these cases, and the TC can
  then discuss it for inclusion in the Errata document to be kept
  on the TC web site.

Anne Anderson
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

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

Powered by eList eXpress LLC