16182 2012-03-01 17:27:00 +0000 wildC035 and wildC036 valid for XSD 1.1? 2012-10-22 09:46:22 +0000 1 1 1 Unclassified XML Schema Test Suite Microsoft tests 2006-11-06 All All REOPENED resolved P2 normal --- 1 am_spamfaenger cmsmcq cmsmcq mike xml.dev public-xml-schema-testsuite oldest_to_newest 64834 0 am_spamfaenger 2012-03-01 17:27:00 +0000 In my opinion the test cases wildC035 and wildC036 of set MS-Wildcards2006-07-15 are valid for XSD 1.1. wildC035 specifies a wildcard with namespace="##target" and wildC036 with namespace="##all". The XML representation for the namespace attribute of xs:any is as follows: namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace | ##local)) ) So the two testcases don't use one of the special values "##any", "##other", "##targetNamespace" and "##local". But the definition of anyURI in XSD 1.1 doesn't prohibit values starting with "##". So "##target" and "##all" are valid values for anyURI and therefore the two test cases should have expected result valid for XSD 1.1. 64886 1 am_spamfaenger 2012-03-02 07:07:15 +0000 There are similar problems with the test cases wildC049-53. In each of these cases one of the special values ##any and ##other is combined with one of the special values ##targetNamespace, ##local or ##other. In XSD 1.0 these cases were invalid because all of these special values were invalid anyURIs. In XSD 1.1 all these values are valid anyURIs, and so these test cases get valid via list of anyURI. Maybe this is not a testsuite bug but more a specification bug. A solution would be to add some schema representation constraint which prohibits the use of URIs starting with ## in the namespace attribute of wildcards. Another solution would be to change the S4S to use a restriction of anyURI which prohibits values starting with ## in basicNamespaceList. 64887 2 am_spamfaenger 2012-03-02 07:34:11 +0000 The same for: set='MS-Wildcards2006-07-15' group='wildC055' test='wildC055' set='MS-Wildcards2006-07-15' group='wildC056' test='wildC056' set='MS-Wildcards2006-07-15' group='wildC057' test='wildC057' set='MS-Wildcards2006-07-15' group='wildC058' test='wildC058' set='MS-Wildcards2006-07-15' group='wildC066' test='wildC066' set='MS-Wildcards2006-07-15' group='wildC067' test='wildC067' set='MS-Wildcards2006-07-15' group='wildF006' test='wildF006' set='MS-Wildcards2006-07-15' group='wildF007' test='wildF007' set='MS-Wildcards2006-07-15' group='wildF008' test='wildF008' set='MS-Wildcards2006-07-15' group='wildF009' test='wildF009' set='MS-Wildcards2006-07-15' group='wildF010' test='wildF010' set='MS-Wildcards2006-07-15' group='wildF012' test='wildF012' set='MS-Wildcards2006-07-15' group='wildF013' test='wildF013' set='MS-Wildcards2006-07-15' group='wildF014' test='wildF014' set='MS-Wildcards2006-07-15' group='wildF015' test='wildF015' set='MS-Wildcards2006-07-15' group='wildF016' test='wildF016' set='MS-Wildcards2006-07-15' group='wildF018' test='wildF018' set='MS-Wildcards2006-07-15' group='wildK002' test='wildK002' set='MS-Wildcards2006-07-15' group='wildK006' test='wildK006' set='MS-Wildcards2006-07-15' group='wildK007' test='wildK007' set='MS-Wildcards2006-07-15' group='wildK020' test='wildK020' set='MS-Wildcards2006-07-15' group='wildK021' test='wildK021' set='MS-Wildcards2006-07-15' group='wildK022' test='wildK022' set='MS-Wildcards2006-07-15' group='wildK023' test='wildK023' set='MS-Wildcards2006-07-15' group='wildK024' test='wildK024' set='MS-Wildcards2006-07-15' group='wildK026' test='wildK026' set='MS-Wildcards2006-07-15' group='wildK027' test='wildK027' set='MS-Wildcards2006-07-15' group='wildK028' test='wildK028' set='MS-Wildcards2006-07-15' group='wildK029' test='wildK029' set='MS-Wildcards2006-07-15' group='wildK038' test='wildK038' set='MS-Wildcards2006-07-15' group='wildN006' test='wildN006' set='MS-Wildcards2006-07-15' group='wildN007' test='wildN007' set='MS-Wildcards2006-07-15' group='wildN008' test='wildN008' set='MS-Wildcards2006-07-15' group='wildN009' test='wildN009' set='MS-Wildcards2006-07-15' group='wildN010' test='wildN010' set='MS-Wildcards2006-07-15' group='wildN012' test='wildN012' set='MS-Wildcards2006-07-15' group='wildN013' test='wildN013' set='MS-Wildcards2006-07-15' group='wildN014' test='wildN014' set='MS-Wildcards2006-07-15' group='wildN015' test='wildN015' set='MS-Wildcards2006-07-15' group='wildN016' test='wildN016' set='MS-Wildcards2006-07-15' group='wildN018' test='wildN018' 64888 3 mike 2012-03-02 08:57:37 +0000 The relevant types (basicNamespaceList and specialNamespaceList) are defined like this: <xs:union memberTypes="xs:anyURI"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="##targetNamespace"/> <xs:enumeration value="##local"/> </xs:restriction> </xs:simpleType> </xs:union> I think what is needed is for the order of the union to be reversed, so the token comes before the anyURI. I'm reclassifying this as a spec bug. 64890 4 am_spamfaenger 2012-03-02 09:18:31 +0000 I think simply changing the order doesn't help. It will still allow values like "##target" which are now valid anyURIs but are not listed in the enumerations - and have no special meaning. Also changing the order doesn't prohibit something like: "##any ##other" which will not match any of the enumerations of the "specialNamespaceList" but is in XSD 1.1 a valid list of anyURIs. I suggest to use a restriction of anyURI which prohibits values starting with "##" (using a pattern) instead of anyURI as memberType in basicNamespaceList. 65210 5 David_E3 2012-03-09 16:56:07 +0000 Tentatively resolved: editorial, and add a note of clarification advising you not to use '##', that an implementation may produce a warning. And: change the test outcomes to match. 65211 6 mike 2012-03-09 16:57:38 +0000 To expand on the resolution: we agree these tests are now valid according to the spec as written, and we have decided not to change the spec, except by adding a note warning users not to do this, and reminding implementors that they have the right to issue a warning. 66277 7 cmsmcq 2012-03-30 01:16:26 +0000 A note has been added to the spec as described in comment 6. 76708 8 cmsmcq 2012-10-19 16:42:41 +0000 The note mentioned in comment 7 is included in the XSD 1.1 Recommendation at http://www.w3.org/TR/xmlschema11-1/#declare-openness so I am marking this bug as resolved. I believe we ought in principle to have asked Andreas Meissl earlier to confirm that this resolution of the issue is acceptable, but the comments here don't show that we did, so I will do so now. Mr. Meissl, if you are content with this resolution of the issue, please indicate so by closing the bug. If you are not content, please reopen the bug with an explanation of why you are not satisfied and of what changes would be satisfactory. If we don't hear from you in the next two weeks, we'll assume you are content and may then close the bug ourselves. Thank you. 76710 9 mike 2012-10-19 17:03:16 +0000 I'm reopening as a bug against the test suite, because it appears that we agreed in the course of discussion that the schemas in these tests are now valid, but we have not marked them as such. 76895 10 xml.dev 2012-10-22 09:46:22 +0000 The resolution is okay for me. I'm just waiting for the changed expected results in the test suite. Best regards, Andreas Meissl