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: [xacml] Is whitespace significant in the XML representation of XACML?

Yes, I'm talking about the string data type.

-----Original Message-----
From: Steven Legg [mailto:steven.legg@viewds.com] 
Sent: woensdag 4 mei 2016 2:24
To: Sinnema, Remon
Cc: David Brossard; xacml
Subject: Re: [xacml] Is whitespace significant in the XML representation of XACML?

Hi Ray,

On 4/05/2016 2:59 AM, Sinnema, Remon wrote:
> Well, that’s the problem. Whitespace in XML may or may not be significant:
> https://www.w3.org/TR/REC-xml/#sec-white-space
> In particular, an XML Schema may define what whitespace is and isn’t significant:
> https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html#r
> f-whiteSpace
> Our schema’s don’t use that, so I guess the default behavior applies, which is that whitespace within elements is significant.

Are you just talking about the string data type or all data types ? Appendix A.2 of the core specification suggests an association between XACML and XML Schema for many of the XACML data types, which would lead one to the conclusion that white space is significant for the XACML string data type, but not for any of the other XACML data types associated with an XML Schema data type. For the remaining data types it is an open question whether leading and trailing white space should be treated as a syntax error or quietly ignored. FWIW, I quietly ignore it.

I agree on the point about the user experience and would not be bothered if the XACML string data type were changed to ignore leading, trailing and multiple internal whitespace characters. That would break applications that have string attribute values with significant whitespace, but I haven't met any and can't think of a realistic use case. A non-breaking profile addition to XACML would be to define a new XACML normalizedString data type and XACML functions to go with it (or extend the existing string functions to apply to normalizedString as well).


> I wonder if this makes sense, though. If we had started out with, say, YAML rather than XML, I doubt we would have come up with a system where the value of an AttributeValue could end with a newline.
> *From:*David Brossard [mailto:david.brossard@axiomatics.com]
> *Sent:* dinsdag 3 mei 2016 18:40
> *To:* Sinnema, Remon
> *Cc:* xacml
> *Subject:* Re: [xacml] Is whitespace significant in the XML representation of XACML?
> Hi Ray
> Wouldn't that be behavior inherited from XML itself where whitespace does matter?
> David
> On May 3, 2016 6:34 PM, "Sinnema, Remon" <remon.sinnema@emc.com <mailto:remon.sinnema@emc.com>> wrote:
> I saw the urn:oasis:names:tc:xacml:1.0:function:string-normalize-spacefunction, which would be superfluous if whitespace were **not** significant, so I assume that it is, but I don’t see this explicitly stated in the spec. Also, it doesn’t seem to provide a good user experience for those of us unlucky enough to write policies by hand. Thoughts?

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