Re: XPath 2.0 support

[Erik Rissanen <erik@axiomatics.com>]

Just from the top of my head, there are a number of places where
non-US-ASCII can be relevant in XACML. There is a <Description> element
which may be human readable and in another language than English. It is
also possible that attributes contain natural language items such as
names of persons or roles.

Personally I have never found namespaces hard to deal with, but I might
have been lucky.

BTW, eliminating namespaces from xpath expressions is not what we are
considering here. The optional feature of xpath is the namespace axis,
which can be used to access namespace nodes directly. This was available
in xpath 1.0, but has been deprecated in 2.0 in favor of other
mechanisms related to namespaces.

Regards,
Erik


sampo@symlabs.com wrote:
> Erik Rissanen writes:
>> 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'm a Finn, BTW.
> US ASCII (7 bits) works across wide range of implementations. Anything
> that is meant to be machine readable or machine processed should stay
> within US ASCII. Why should it not? Or should we start writing these
> specs in a language other than english? Or perhaps we should just
> adopt a binary encoding like ASN.1 ;-)
> Now, if there are texts to be displayed to the user or accepted from
> the user (e.g. disclaimers, consent questions, and prompts), then
> I see the point venturing beyound US ACSII (7 bit). But are there
> any such texts in XACML?
>> 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 a 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.
>
> Leaving it open is of course a spec layering and composability issue,
> but I can tell from experience that the namespaces are a major
> source of interoperability confusions. Anything that makes them
> even more confusing is bound to be a disaster.
>>>> 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?
>
> I have seen XPath understood in many ways and certainly the possibility
> of the namespaces in the expressions is a major area of confusion
> that creates interoperability problems. Especially the fact that
> the namespace prefix can be arbitrarily chosen by the XML document tends
> to create major problems. The worst of this is that it is not a
> compile time decision: you have to jump through all sorts of hoops
> at runtime to see what the request actually chose to use for a prefix.
> Not nailing it down is asking for trouble. Mind you that most
> people DO NOT implement XPath agains XML database. Instead, they
> map XPath to their existing RDBM or LDAP backends. Plenty of scope
> for interpretation, a lot of rope to hang yourself with.
>> 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 
>
> Eliminating namespaces from XPath expressions is by far the best
> approach. In fact many existing implementations already ignore
> them anyway as it is virtually impossible to be interoperable
> if you insist on them.
> Cheers,
> --Sampo
>> 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,
>> Erik
> __________________________________________________________________
> Sym  | Sampo Kellomaki  ______| Identity Architect, Federated SSO
> ____ | +351-918.731.007 ______| Liberty ID-WSF DirectoryScript
> labs | skype: sampo.kellomaki | LDAP SOAP PlainDoc Crypto C Perl
>