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] WI#70. Legal values for string DataType


On Thu, 2004-04-22 at 11:43, Anne Anderson wrote:
> Tim says this has not been resolved, and would like input from
> Seth and/or others.

I have been investigating it, but can find no explination for the
behavior that Tim is seeing. In the validators I have used the current
schemas work correctly with regard to AttributeValues. I think that Bill
tried the version of XMLSpy that he uses, and it also worked correctly
(Tim, are you using an older version?).

> The problem is that, in Section 4.2.4.4 example, in order to make
> the string valid in XML Spy, he had to enclose the string in
> <xs:string> tags.  He would like to remove those tags, but then
> the examples will not validate in XML Spy.

Since the example _will_ validate in most other validators we've tried
(including some versions of XMLSpy), and since we've already agreed on
the correct behavior (whether or not this requires us to tweak the
schema), I think we should make the change to the examples now. Also,
let's be specific: the example won't validate in a particular version of
XMLSpy that Tim is using.

> The agreement on the list was that <xs:string> should not be
> needed, but we want our examples to validate.  XML Spy tends to
> be lenient, so this is a bit of a problem.

No, the agreement on the list was that string values should not contain
un-escaped elements. The xs:string addition actually has no meaning in
the XACML specification, they just let the example validate in one
parser. It's still invalid XACML, so it's still an invalid example (more
support for my suggestion above).

> This problem first arose when we created the Expression group and
> made AttributeValue a part of it.

I still believe the problem comes from AttributeValue now extending to
complexContent, but I haven't been able to verify this.


seth



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