BUGS in MS Implementation of XmlSchema:\r
\r
+Here we summarize bugs found in MS.NET, including some comment excerpt from\r
+Microsoft development team (as of 2004/07).\r
+\r
+\r
001. Does not allow duplicate values in lists for final* and block* attributes. \r
For example "restriction restriction" is not allowed even though its a valid\r
value for blockDefault.\r
\r
+(MS: This is fixed in .NET 2.0)\r
+\r
+\r
002. Resets the minOccurs to 0 if maxOccurs="0", whereas it should raise an error.\r
\r
+(MS: This WON'T be fixed in .NET 2.0. MS users may depend on this bug.)\r
+\r
+\r
003. Allows abstract="true" in the a localElement whereas it is not allowed.\r
<?xml version="1.0"?>\r
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xsdtesting" xmlns:x="http://xsdtesting" elementFormDefault="qualified">\r
</xsd:element>\r
</xsd:schema>\r
\r
+(MS: This is fixed in .NET 2.0)\r
+\r
+\r
004. QName value constraint\r
\r
When xs:QName based type is specified to an attribute or element\r
default or fixed value), even though they have those namespace \r
declaration by XmlSerializerNamespaces.\r
\r
+(MS: This is fixed in .NET 2.0)\r
+\r
+\r
005. derivation by extension of xs:all\r
\r
As it is discussed on w3c xmlschema-dev ML, MS System.Xml.Schema\r
ctH019.xsd, ctH020.xsd, ctH021.xsd, ctH022.xsd, ctH023.xsd, ctJ001.xsd\r
and in msxsdtest/ModelGroups: mgA016.xsd, mgO007.xsd (9 testcases).\r
\r
+(MS: This is fixed in .NET 2.0)\r
+\r
+\r
006. xs:all minOccurs="0" not allowed\r
\r
W3C WXS Structures REC. says that model group xs:all is limited to have\r
\r
Related msxsdtest is ParticlesEa022.xsd\r
\r
+(MS: This happens only when a group ref targets to xs:all. This is bug.)\r
+\r
+\r
007. Insufficient unique particle attribution of xs:any\r
\r
MS.NET allows <xs:choice><xs:any /><xs:element ... /></xs:choice>.\r
\r
+ <del>\r
Related msxsdtests are: ParticlesJd002.xsd, ParticlesJd003.xsd and\r
ParticlesJd004.xsd. \r
+ </del>\r
+ [Update] They are sequence not choice. Thus does not apply to this\r
+ case. MS validator handles such schema as invalid correctly.\r
+\r
ParticlesIb001.xsd is also related, but it is not necessarily said as\r
incorrect. Both elements are of the same type, so *in a sense* they are\r
the same declaration. MSV, XSV and I stands different.\r
\r
-008. Occurence Range OK (3.9.6) incorrectly assessed\r
+[Still on discussion on ParticlesIb001.xsd]\r
+\r
+\r
+<del>008. Occurence Range OK (3.9.6) incorrectly assessed</del>\r
+\r
+ [Update] MS team pointed out that it is incorrect and I found that \r
+ XML Schema Structures 3.3.2 explicitly denotes that when minOccurs=\r
+ maxOccurs=0 it corresponds to no component at all.\r
\r
Particles that have maxOccurs="0" looks simply ignored *before*\r
evaluating particle restriction valid, but it might get incorrect\r
\r
Related msxsdtest is groupG001.xsd.\r
\r
+\r
009. derived list incorrectly allowed\r
\r
"Type Derivation OK" by list simple type of atomic simple type is\r
\r
Related msxsdtests are elemT015.xsd and elemT022.xsd.\r
\r
+(MS: This will be fixed in the next version of .NET 2.0)\r
+\r
+\r
010. derived union incorrectly allowed\r
\r
Similar problem to No.9 above resides in xs:union. Derived union type\r
\r
Related msxsdtest is elemT014.xsd.\r
\r
-011. schema finalDefault with list and/or union\r
+[ditto]\r
+\r
+\r
+<del>011. schema finalDefault with list and/or union</del>\r
+\r
+ [Update] This is not MS bug. We have to fix this problem. XML Schema\r
+ errata corrected this part of the spec by allowing 'list'.\r
\r
In xs:schema, finalDefault = (#all | List of (extension | restriction)),\r
but MS.NET failed to handle blockDefault='list' as an error.\r
\r
Related msxsdtest is stF034.xsd and stF036.xsd.\r
\r
+\r
012. derived types cannot duplicate fixed facet\r
\r
- If you have a facet like <xsd:minLength value="5" fixed="true" />, you should\r
- be able to have <xsd:minLength value="5" /> in restrictions of it, as long as\r
- the values are the same. MS says: \r
- "Base type has {fixed} equal to true."\r
+ If you have a facet like <xsd:minLength value="5" fixed="true" />, \r
+ you should be able to have <xsd:minLength value="5" /> in \r
+ restrictions of it, as long as the values are the same. MS says: \r
+ "Base type has {fixed} equal to true."\r
+\r
+ XML-Schema part2 Datatype, 4.3.2.1: \r
+ "If {fixed} is true, then types for which the current type is the\r
+ {base type definition} cannot specify a value for minLength other than\r
+ {value}."\r
+\r
+ Which implies that you can specify a value for minLength that is the\r
+ same as {value}.\r
\r
- XML-Schema part2 Datatype, 4.3.2.1: \r
- "If {fixed} is true, then types for which the current type is the {base\r
- type definition} cannot specify a value for minLength other than\r
- {value}."\r
+(MS: This is bug.)\r
\r
- Which implies that you can specify a value for minLength that is the same as\r
- {value}.\r
\r
013. Some facets are incorrectly allowed for list simple type.\r
\r
minLength, maxLength, pattern and enumeration are allowed. However, MS\r
implementation allows whitespace (and possibly and so on).\r
\r
-014. Incorrectly disallowed mixed derivation with empty content from elementOnly\r
+(MS: "whitespace" is incorrectly allowed. It is bug.)\r
+\r
+\r
+<del>014. Incorrectly disallowed mixed derivation with empty content from\r
+elementOnly</del>\r
+\r
+ [Update] MS team pointed out that XSD Errata replaced -explicit \r
+ content- with -effective content- . Thus, such schema should be\r
+ rejected. (See E1-5 of http://www.w3.org/2001/05/xmlschema-errata .)\r
\r
When a complexType whose mixed='true' and -explicit content- is empty,\r
- is derived from a complexType whose {content type} is ElementOnly,\r
+ and is derived from a complexType whose {content type} is ElementOnly,\r
MS.NET rejects such schema. But 3.4.2 (complex content Schema\r
Component) especially 2.1 of {content type} does not say it is an error.\r
\r
Related msxsdtest: ctF008.xsd\r
\r
+\r
+015. Included schema ignores incorrect element name which belongs to \r
+XmlSchema.Namespace\r
+\r
+ MS Schema compiler fails to catch an error when an incorrect schema\r
+ (such as below) is included by any other schemas:\r
+\r
+ <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'>\r
+ <xs:foo />\r
+ </xs:schema>\r
+\r
+ This does not apply to general compilation error such as missing \r
+ sub components that should result in an error.\r
+\r
+ This seems fixed in Whidbey.\r
projects / mono.git / blobdiff