RE: [xacml] functions specifications

[Polar Humenn <polar@syr.edu>]

Thanks Anne! It certainly helps with all the "other" work I've got to do.
Cheers,
-Polar

On Tue, 10 Sep 2002, Anne Anderson wrote:

> These are my responses to Polar's list of "specification needed"
> function items begins.  This is as far as I could get today, and
> I have to travel for the next few days.
>
> -Anne
>
> All xs: datatypes are defined in XML Schema, Part 2
>   [http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/]
>
> Special derived types from XQuery 1.0 and XPath 2.0 Functions and Operators
>   [http://www.w3.org/TR/xquery-operators/]
>       xf:dayTimeDuration
>       xf:yearMonthDuration
>
> Source for XPATH function (xf:) and operator (op:) definitions is
>   [http://www.w3.org/TR/xquery-operators/].  Unless otherwise
>   referenced, section numbers are from this document.
>
>                    return    1st Arg   2nd Arg
>                    type
> string-equal      xs:boolean xs:string     xs:string
> - Suggestion: returns "true" iff the two arguments match byte by
>   byte using integer-equal.  No normalization or collation is done.
> - Note: there is no xf:equals.  Closest is xf:compare, but that
>   depends on complicated collation algorithms and hierarchies of
>   collations algorithms, so is more complex than we want.
>
>
>    Q: leading and trailing spaces, multiple lines, etc.
> Use Michiharu's suggested new function (possibly with my simpler
> suggested semantics):
>
> normalized-string-equal   xs:boolean  xs:string   xs:string
> - Implemented as
>   function:string-equal(xf:normalize-space(1st Arg),xf:normalize-space(2nd Arg)
> - Alternative: support xf:normalize-space as a separate function
>   that may be called inside any string function.
>
> date-equal        xs:boolean xs:date       xs:date
> - Use op:date-equal, Section 8.3.11
>
> time-equal        xs:boolean xs:time       xs:time
> - Use op:time-equal, Section 8.3.14
>
> dateTime-equal    xs:boolean xs:dateTime   xs:dateTime
> - Use op:dateTime-equal, Section 8.3.8
>
> anyURI-equal      xs:boolean xs:anyURI     xs:anyURI
> - Use op:anyURI-equal, Section 10.2.1
>
> x500Name-equal    xs:boolean xs:x500Name   xs:x500Name
>   Q:   Do we have an adequate specification on this from pkix?
> - Turns out, no.  PKIX does not deal with string representations
>   of X500 Distinguished Names.
> - Use:
>   "Returns true if and only if each Relative Distinguished Name
>   in the two arguments matches.  Two Relative Distinguished Names
>   match if and only if the OIDs match AND if the values, with
>   leading and trailing spaces removed, match using integer-equal
>   on a byte-by-byte basis.  OIDs may be expressed either using a
>   sequence of decimal integers separated by ".", or by character
>   strings.  If both OIDs are expressed in dotted-decimal format,
>   then the OIDs are compared using string-equal.  If both OIDs
>   are expressed using character strings, then the characters
>   strings are normalized to lower case, then compared using
>   string-equal.  If one OID is expressed using a character
>   string, and the other OID is expressed using dotted-decimal
>   format, then the character string must be from the following
>   set (IETF RFC 2253: Lightweight Directory Access Protocol (v3):
>   UTF-8 String Representation of Distinguished Names), and its
>   corresponding dotted decimal representation must match the OID
>   in the other RDN.
>
>     String  X.500 AttributeType      Dotted decimal notation
>     ------------------------------   -----------------------
>     CN      commonName               2.5.4.3
>     L       localityName             2.5.4.7
>     ST      stateOrProvinceName      2.5.4.8
>     O       organizationName         2.5.4.10
>     OU      organizationalUnitName   2.5.4.11
>     C       countryName              2.5.4.6
>     STREET  streetAddress            2.5.4.9
>     DC      domainComponent          0.9.2342.19200300.100.1.25
>     UID     userid                   0.9.2342.19200300.100.1.1
> - In the future, we may want to add an optional third argument
>   specifying the collation to use for Unicode characters.  There
>   is an effort underway in the IETF to define a standard for
>   this.
>
> rfc822Name-equal  xs:boolean xs:rfc822Name xs:rfc822Name
> - Returns true iff, after conversion to lower-case, the two names
>   match when compared byte-by-byte using integer-equal.
>
> hex-equal         xs:boolean xs:hex        xs:hex
>    Q: Is the type xs:hex or xs:hexBinary?
> xs:hexBinary
>
>    Q: leading and trailing spaces, multiple lines, etc.
> Not allowed.
>
>     From http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#hexBinary
>
>         3.2.15 hexBinary
>
>         [Definition:] hexBinary represents arbitrary hex-encoded
>         binary data. The ˇvalue spaceˇ of hexBinary is the set of
>         finite-length sequences of binary octets.
>
>         3.2.15.1 Lexical Representation
>
>         hexBinary has a lexical representation where each binary
>         octet is encoded as a character tuple, consisting of two
>         hexadecimal digits ([0-9a-fA-F]) representing the octet
>         code. For example, "0FB7" is a hex encoding for the
>         16-bit integer 4023 (whose binary representation is
>         111110110111).
>
>         3.2.15.2 Canonical Rrepresentation
>
>         The canonical representation for hexBinary is defined by
>         prohibiting certain options from the Lexical
>         Representation (§3.2.15.1). Specifically, the lower case
>         hexadecimal digits ([a-f]) are not allowed.
>   TBD
>
> base64-equal      xs:boolean xs:base64     xs:base64
>    Q: Is the type xs:base64 or xs:base64Binary?
> xs:base64Binary
>
>    Q: leading and trailing spaces, multiple lines, etc.
> Not allowed.
>
>         3.2.16 base64Binary
>
>         [Definition:] base64Binary represents Base64-encoded
>         arbitrary binary data. The ˇvalue spaceˇ of base64Binary
>         is the set of finite-length sequences of binary
>         octets. For base64Binary data the entire binary stream is
>         encoded using the Base64 Content-Transfer-Encoding
>         defined in Section 6.8 of [RFC 2045].
>   TBD
>
> string-greater-than              xs:boolean xs:string  xs:string
> string-greater-than-or-equal     xs:boolean xs:string  xs:string
>
>    Q: leading and trailing spaces, multiple lines, etc.
> - Suggestion: support xf:normalize-space.
>
>    Q: What if two different international strings?
> - Suggestion: for now, compare byte-by-byte using
>   integer-greater-than and integer-equal.  In the future, we
>   probably want to add an optional third argument to support
>   "collations" (xf:Section 6.2) to handle international strings.
>
> time-greater-than                xs:boolean xs:time    xs:time
> time-greater-than-or-equal       xs:boolean xs:time    xs:time
>    Q: Are these relative to only one day? with Timezones?
>   TBD
>
> date-greater-than                xs:boolean xs:date    xs:date
> date-greater-than-or-equal       xs:boolean xs:date    xs:date
> datetime-greater-than            xs:boolean xs:date    xs:date
> datetime-greater-than-or-equal   xs:boolean xs:date    xs:date
>  TBD
>
> string-match      xs:boolean  xs:string      xs:string
> -equates to xf:match; second argument is a regular expression.  Regular
>  expression syntax is defined in "6.3.15.1 Regular Expression Syntax"
>
> rfc822Name-match  xs:boolean  xs:rfc822Name  xs:rfc822Name
> - An rfc822 name consists of a <local-part> followed by "@"
>   followed by <domain>.
> - TBD
>
> x500Name-match    xs:boolean  xs:x500Name    xs:x500Name
>   TBD
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>