RE: [xacml] WI#70. Legal values for string DataType

[Tim Moses <tim.moses@entrust.com>]

Seth - I am using version 4.0 of XMLSpy.  Attached is an example that would
not validate if I were to remove the <xs:string> tags.  Nevertheless, I'll
remove those tags when I publish WD 10.  All the best.  Tim.

-----Original Message-----
From: Seth Proctor [mailto:Seth.Proctor@Sun.COM] 
Sent: Thursday, April 22, 2004 11:53 AM
To: Anne.Anderson@Sun.COM
Cc: XACML TC
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


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p
hp.

Rule 4.xml