[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Open issues and action items for Hierarchical Resources
These are the open issues and associated action items resulting from our discussion of Hierarchical Resources at today's TC meeting. 1) Daniel: if this Profile is approved, certain portions of the core spec should be removed or modified. Should these changes be done before we try to approve the Hierarchical Resources Profile? [ACTION ITEM] Anne will post mods to the core spec before we try to vote to approve the Hierarchical Resources Profile. 2) Tony: How to know which portions of a Profile an implementation supports, and how to specify that in policies or requests. This is an issue for any XACML profile, not just hierarchical resources. [ACTION ITEM]: Hal and Tony will work together to prepare a specific proposal. 3) Michiharu: anyURI-match not yet fully specified. He has posted comments on this (10 June "URI match function"). This function would be specified in the core specification, as it does not apply just to hierarchical resources. Since the Hierarchical Resources Profile does not describe the semantics of these functions, and just points to the definition to be included in the core specification, the only changes needed to the Hierarchical Resources Profile would be editorial - include the final list of URI/URL matching function names. [ACTION ITEM] Michiharu will work with Tim on preparing a specific, updated, corrected proposal. 4) Michiharu: it would be good to have use cases or examples for using the functionality described in the profile. [ACTION ITEM] Michiharu will provide use cases for XML document resources. Anne and Daniel will provide use cases for non-XMl document resources. 5) Michiharu: still studying issue of "document-id" Attribute versus a document identifier resource-id Attribute. [ACTION ITEM] Michiharu will post comments after completing the function. 6) Seth: Is the new xpath-expression DataType really needed? Should it be defined in the core specification? Should current uses of "string to be interpreted as XPath expression" be changed to use xpath-expression data type? Issue is that currently, specific AttributeIds are associated with the use of "string to be interpreted as as an XPath expression", and not a DataType. [ACTION ITEM] Anne & Seth will look at places where "string to be interpreted as XPath" is currently used and see if new ID or DataType needed. Anne -- 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] | [List Home]