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: Re: XPath 2.0 support

Thanks for the feedback, Sampo! See responses inline.

sampo@symlabs.com wrote:
> Erik Rissanen writes:
>> 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.
> I guess all (or just most?) of XACML stays within US ASCII which
> is trivially handled by UTF-8 so any further versions of Unicode
> are really only of theoretical interest. A much more important
> issue is whether UTF-8 is mandatory or whether UTF-16 is also
> allowed (it should not be)?
I think this refers to the character set version, not how unicode 
character strings are encoded into octet streams (utf-8, utf-16, etc). 
The encoding would be given in the <?xml ?> processing instruction, and 
is outside the scope of XPath and XACML.

I don't think we should in any way limit ourselves to US ASCII. As a 
Swede/Finn, I have had enough of trouble with the US ASCII legacy 
already. :-)

I think we should leave it to implementors so XACML can stay current as 
Unicode is updated.

>> 3.    The implicit timezone.
>> * We define this as UTC? Or should this be XACML implementation defined?
> Mandate UTC.

I agree with you on this. It seems as one of those things which will 
make Mars spacecraft crash some day in the future otherwise.

>> 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.)
> Since namespace handlingis a major interop problem, I think leaving
> this open is bad idea. We should mandate one or the other.

I am inclined to leave this open for later versions of XML. I must admit 
that I don't fully understand the ramifications of this issue, but I 
would expect that the <?xml version="1.0"> header would clearly indicate 
which version is in use, so implementations can interop without 
ambiguity as long as they implement the same version. I am concerned 
that if we say that XACML policies may only be encoded as XML 1.0, this 
might be a problem in the future when the rest of the world moves to 1.1.

>> 7.    Whether the implementation supports the namespace axis.
>> * We leave this to be defined by XACML implementations.
> Again: namespaces are a headache. Only allow one way.

Could you clarify in what way the namespace axis is a headache?

If we have to go with either one, I suppose going without is the right 
way to do since it has been deprecated by the xpath standard anyway, and 
is there only as an option for backwards compatibility with xpath 1.0. 
XACML users which use the namespace axis can stay with xpath 1.0.

Best regards,

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