[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml-comment] Re: [xacml] Errata errata ([XF] and [XQO])
>> By the way, why do we have two reference [XF] and [XQO] for the >> xquery-operators WD? >> If there is no reasonable reason, we should merge them into a single >> reference. If there is no reason, why don't you merge two references [XF] and [XQO] into the following LATEST spec: http://www.w3.org/TR/2002/WD-xquery-operators-20021115/ >> there is no Section 6.3.15 in the current >> draft to which http://www.w3.org/TR/xquery-operators/ points! Regular Expression Syntax is in Section 6.4.16.1 in the latest draft. Satoshi Hada IBM Tokyo Research Laboratory mailto:satoshih@jp.ibm.com Satoshi Hada/Japan/IBM@IB To: Anne.Anderson@Sun.com MJP cc: XACML TC <xacml@lists.oasis-open.org>, XACML COMMENT <xacml-comment@lists.oasis-open.org> 2003/02/07 09:57 Subject: [xacml-comment] Re: [xacml] Errata errata ([XF] and [XQO]) >>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 6.3.15.1 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 >> http://lists.oasis-open.org/archives/xacml-comment/200301/msg00007.html >> (two errata above): there is no Section 6.3.15 in the current >> draft to which http://www.w3.org/TR/xquery-operators/ points! I agree that a specific version (a specific date) of the xqeury-operators should be referenced in Section 11. However, the data type URIs for yearMonthDuration and dayTimeDuration can be whatever we like. By the way, why do we have two reference [XF] and [XQO] for the xquery-operators WD? If there is no reasonable reason, we should merge them into a single reference. Satoshi Hada IBM Tokyo Research Laboratory mailto:satoshih@jp.ibm.com Anne Anderson <Anne.Anderson@Su To: XACML TC <xacml@lists.oasis-open.org> n.com> cc: XACML COMMENT <xacml-comment@lists.oasis-open.org> Subject: [xacml] Errata errata 2003/02/07 02:18 Please respond to Anne.Anderson 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 http://lists.oasis-open.org/archives/xacml/200302/msg00006.html) and on the updated spec (in the same e-mail) that incorporated them. 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 incorrect. Options: Replace DataType attribute value with http://www.w3.org/2001/XMLSchema#string. 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 "http://www.w3.org/2001/XMLSchema#string". 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 "http://www.w3.org/TR/2002/WD-xquery-operators-20020816/", since it was that snapshot of the Working Draft that we defined our operators and types against. Someone check me on this, please. 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 3.3.2.3". However, Section 3.3.2.3 is about a policy rather than a set of policies. So it should be Section 3.3.3.2 rather than 3.3.2.3. Options: Update section references. Anne: Section 3.3.3.2 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 3.3.3.2 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 6.3.15.1 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 http://lists.oasis-open.org/archives/xacml-comment/200301/msg00007.html (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". Options: 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 "URI-equality". We could always change our minds, but this was intended at the time. 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 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC