Rich,
I think that it does introduce complexity in that once compound
actions are introduced the relationship between them is ambiguous
unless further machinery/description is also introduced to handle it.
The comma used in "read,write" lacks referenceable meaning in the
current specification and therefore lends itself to open
interpretation. In general we have always tried to avoid this type of
situation because it tends to lessen the chances for interoperability.
Therefore I would offer that is not just a complexity/performance
issue. One could argue that the TC doesn't dictate attribute values,
however it seems to me that there is merit in discouraging the
creation of non-normative syntax for creating compound attribute
values, particularly since there seems to be a viable alternative at
hand that provides the desired functionality.
b
On Sep 18, 2008, at 10:31 AM, Rich.Levinson wrote:
> Hi Erik,
>
> I agree there are multiple ways to address the problem. Personally,
> I do not believe the approach I have suggested necessarily results
> in any significantly increased complexity.
>
> However, I do not think that can be the basis for how the TC
> presents its recommendations and guidelines. For example, the fact
> that the whole policy structure and requests and responses are
> written in the spec in xml does not constrain the implementor to use
> xml at all, as I understand it.
>
> It is very possible that different implementation technologies lend
> themselves to more or less efficient policy processing depending on
> how one writes the policies. Just because an XML representation of a
> Policy is complex doesn't mean that the underlying implementation of
> that Policy necessarily has to be complex.
>
> Thanks,
> Rich
