We might also address the related issue of the standard XACML 2.0
datatypes and functions that are defined using references to "XQuery 1.0
and XPath 2.0 Functions and Operators," W3C Working Draft, 16 August
2002, at http://www.w3.org/TR/2002/WD-xquery-operators-20020816. Note
this is a Working Draft, and not a W3C approved Recommendation. For the
ITU-T standard, since ITU-T does not allow normative references to
non-standards, we inserted into XACML 2.0 itself the text from that
draft necessary to define the affected types and functions, removing the
external dependencies.
If we can determine that the definitions in the XPath 2.0 Recommendation
are consistent with the definitions used in XACML 2.0, then we could
reference the functions in XPath 2.0 and still preserve backwards
compatibility. By referencing the XPath 2.0 functions, XACML
implementations could re-use XPath 2.0 function implementations, or at
least feel more free to do so.
The affected datatypes are:
http://www.w3.org/TR/2002/WD-xquery-operators-20020816#dayTimeDuration
http://www.w3.org/TR/2002/WD-xquery-operators-20020816#yearMonthDuration
The affected functions, which all have prefix
"urn:oasis:names:tc:xacml:1.0:function:...", are:
date-equal
time-equal
dateTime-equal
dayTimeDuration-equal
yearMonthDuration-equal
anyURI-equal
dateTime-add-dayTimeDuration
dateTime-add-yearMonthDuration
dateTime-subtract-dayTimeDuration
dateTime-subtract-yearMonthDuration
date-add-yearMonthDuration
date-subtract-yearMonthDuration
dateTime-greater-than
dateTime-greater-than-or-equal
dateTime-less-than
dateTime-less-than-or-equal
date-greater-than
date-greater-than-or-equal
date-less-than
date-less-than-or-equal
xpath-node-equal
xpath-node-match
Regards,
Anne
Erik Rissanen wrote:
> All,
>
> And Daniel in particular, whose feedback I would appreciate a lot.
>
> I had a look at what is needed for xpath 2.0 support (listed as issue 67).
>
> XPath 2.0 lists a number of details which are implementation defined.
> Here is a list of them, together with proposals for what we should do or
> questions where I didn’t know. I have left a lot to be defined by XACML
> implementations, which might reduce interoperability, but many of these
> seem to be issues which might evolve over time, such as integer
> precision, so I left them like this. Another reason for leaving them
> implementation defined is that it makes implementing easier since
> implementations in many cases can simply call whatever functionality is
> available natively on the particular platform.
>
> Is interoperability or flexibility/ease of implementation more important?
>
> Below are items listed at:
> http://www.w3.org/TR/xpath20/#id-impl-defined-items
>
> 1. The version of Unicode that is used to construct expressions.
> * We can leave this to be defined by XACML implementations, with the
> recommendation that the most recent version is used.
>
> 2. The statically-known collations.
> * We leave this to be defined by XACML implementations.
>
> 3. The implicit timezone.
> * We define this as UTC? Or should this be XACML implementation defined?
>
> 4. The circumstances in which warnings are raised, and the ways in
> which warnings are handled.
> * We leave this to be defined by XACML implementations.
>
> 5. The method by which errors are reported to the external processing
> environment.
> * An xpath error causes the XACML processing error status with
> implementation specific status details.
>
> 6. Whether the implementation is based on the rules of [XML 1.0] and
> [XML Names] or the rules of [XML 1.1] and [XML Names 1.1]. One of these
> sets of rules must be applied consistently by all aspects of the
> implementation.
> * We leave this to be defined by XACML implementations. (I am unsure
> what to do here. As far as I understand most people still use XML 1.0,
> but for the future, we might want to allow for XML 1.1.)
>
> 7. Whether the implementation supports the namespace axis.
> * We leave this to be defined by XACML implementations.
>
> 8. Any static typing extensions supported by the implementation, if
> the Static Typing Feature is supported.
> * We leave this to be defined by XACML implementations.
>
> Below are items listed at:
> http://www.w3.org/TR/xpath-datamodel/#implementation-defined
>
> 1. Support for additional user-defined or implementation-defined
> types is implementation-defined. (See 2.6.1 Representation of Types)
> * We leave this to be defined by XACML implementations.
>
> 2. Some typed values in the data model are undefined. Attempting to
> access an undefined property is always an error. Behavior in these cases
> is implementation-defined and the host language is responsible for
> determining the result. (See 5 Accessors)
> * Can we define these to cause XACML processing errors?
>
> Below are items listed at:
> http://www.w3.org/TR/xquery-operators/#impl-def
>
> 1. The destination of the trace output is •implementation-defined•.
> See 4 The Trace Function.
> * We leave this to be defined by XACML implementations.
>
> 2. For xs:integer operations, implementations that support
> limited-precision integer operations •must• either raise an error
> [err:FOAR0002] or provide an •implementation-defined• mechanism that
> allows users to choose between raising an error and returning a result
> that is modulo the largest representable integer value. See 6.2
> Operators on Numeric Values.
> * We leave this to be defined by XACML implementations. In case there is
> an error, it is an XACML processing error status.
>
> 3. For xs:decimal values the number of digits of precision returned
> by the numeric operators is •implementation-defined•. See 6.2 Operators
> on Numeric Values. See also 17.1.3.3 Casting to xs:decimal and 17.1.3.4
> Casting to xs:integer
> * We leave this to be defined by XACML implementations.
>
> 4. If the number of digits in the result of a numeric operation
> exceeds the number of digits that the implementation supports, the
> result is truncated or rounded in an •implementation-defined• manner.
> See 6.2 Operators on Numeric Values. See also 17.1.3.3 Casting to
> xs:decimal and 17.1.3.4 Casting to xs:integer
> * We leave this to be defined by XACML implementations.
>
> 5. It is •implementation-defined• which version of Unicode is
> supported by the features defined in this specification, but it is
> recommended that the most recent version of Unicode be used. See 7.1
> String Types.
> * We can leave this to be defined by XACML implementations, with the
> recommendation that the most recent version is used.
>
> 6. For 7.4.6 fn:normalize-unicode, conforming implementations •must•
> support normalization form "NFC" and •may• support normalization forms
> "NFD", "NFKC", "NFKD", "FULLY-NORMALIZED". They •may• also support other
> normalization forms with •implementation-defined• semantics.
> * We leave this to be defined by XACML implementations.
>
> 7. The ability to decompose strings into collation units suitable for
> substring matching is an •implementation-defined• property of a
> collation. See 7.5 Functions Based on Substring Matching.
> * We leave this to be defined by XACML implementations.
>
> 8. All minimally conforming processors •must• support year values
> with a minimum of 4 digits (i.e., YYYY) and a minimum fractional second
> precision of 1 millisecond or three digits (i.e., s.sss). However,
> conforming processors •may• set larger •implementation-defined• limits
> on the maximum number of digits they support in these two situations.
> See 10.1.1 Limits and Precision.
> * We leave this to be defined by XACML implementations. (I thought that
> XACML limited all time values to millisecond precision, but I couldn’t
> find that when I looked in the spec. If that is really the case, this
> should be the same.)
>
> 9. The result of casting a string to xs:decimal, when the resulting
> value is not too large or too small but nevertheless has too many
> decimal digits to be accurately represented, is implementation-defined.
> See 17.1.1 Casting from xs:string and xs:untypedAtomic.
> * We leave this to be defined by XACML implementations.
>
> 10. Various aspects of the processing provided by 15.5.4 fn:doc are
> •implementation-defined•. Implementations may provide external
> configuration options that allow any aspect of the processing to be
> controlled by the user.
> * We leave this to be defined by XACML implementations.
>
> 11. The manner in which implementations provide options to weaken the
> •stable• characteristic of 15.5.6 fn:collection and 15.5.4 fn:doc are
> •implementation-defined•.
> * We leave this to be defined by XACML implementations.
>
> Best regards,
> Erik
>
>
--
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