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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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


Subject: Re: [xacml-comment] FW: [xacml] All the issues from the commentslist


> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Wednesday, September 03, 2008 1:47 PM
> To: XACML TC
> Subject: [xacml] All the issues from the comments list
> 
> All,

Thank you Erik for taking the time of looking into all these issues.
After sending all those mails, I had feared that I'd only be taken as a
troll. I'm relieved that things went much better. :)

> ISSUE E: Definition of string equal
> 
> http://lists.oasis-open.org/archives/xacml-comment/200808/msg00008.html
> 
> Since we are XML-based, our strings are unicode strings.
> 
> OPEN ISSUE: String comparison in unicode is really complicated. See here:
> 
> http://www.w3.org/TR/xquery-operators/#string-compare
> 
> I haven't tried to understand this yet.

Sorry that I didn't mention the solution I had in mind: The simplest
idea would be to specify that string-equal compares the strings
character-by-character (instead of byte-by-byte).

> ISSUE L: Integer overflow in conversion
> 
> http://lists.oasis-open.org/archives/xacml-comment/200808/msg00017.html
> 
> OPEN ISSUE: I think this should be such that the result is
> indeterminate, but I haven't thought about exact phrasing.

I think many current applications just truncate the additional
precision, so this may be another solution to the problem. The wording
could then be "double-to-integer shall return the #double number that is
closer than any other to its argument" (watch for rounding) or something
similar.

> ISSUE N: Various typos and issues
> 
> http://lists.oasis-open.org/archives/xacml-comment/200808/msg00019.html
> 
> PROPOSED ACTIONS:
> 
> [...]
> 
> There is no "duration-equal" equal function in XACML, so I don't
> understand what he means with that. The two *Duration-equal seem to be fine.

Appendix A.3.1 mentions the duration-equal function, while in section
10.2.8, only dayTimeDuration-equal and yearMonthDuration-equal are
mentioned.

> Section 4.2.4.2 example variable names should be as they are. No need to
> change them just because they have a "horrible" appearance.

Sorry for my bad choice of words. :)

> ISSUE Q: Misc multiple issues
> 
> http://lists.oasis-open.org/archives/xacml-comment/200808/msg00022.html
> 
> Regarding the EffectType, Section 5.22 in the draft of 3.0 I am looking
> at has a definition of simple type EffectType, so I don't see any need
> to make a change on this issue.

Mine doesn't mention the allowed values (Permit, Deny). It only says
that it "defines the values allowed for the Effect attribute". The
values are clear from the XML Schema fragment, but that is not normative.

> Regarding the "xacml:" prefix, I don't understand what is intended with
> this comment. I couldn't find any use of this prefix.

I don't remember exactly. Maybe I meant sections 7.3 and 10.2.1. And
maybe I meant the XML Schema fragments, although I should have known better.

> ISSUE R: User defined set functions.
> 
> http://lists.oasis-open.org/archives/xacml-comment/200808/msg00023.html
> 
> No, there is no way to use the set functions on user defined data types.
> Users defining data types need to define their own functions for them as
> well. If they want set functions for the new data type, those must be
> explicitly defined. I think this is correct, since there is no way to
> define set functions in general because the set functions depend on for
> instance equality testing for their implementation/definition, and
> equality may not always be defined for all data types. I propose that we
> make no changes here.

Thanks for the clarification.

Roland


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