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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: XPath 2.0 support


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




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