This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
1. It seems clear that elements in the xs: namespace are permitted to appear inside xs:documentation and xs:appInfo elements. It's less clear what happens to them if they are so included. 2. As a minimum, there should be a statement somewhere that such elements do not generate any schema components and do not have to satisfy the (prose) rules for the XML representation of schema components. 3. Schema documents are required to satisfy the schema for schema documents, and this schema imposes lax validation on the contents of xs:documentation and xs:appInfo elements. It does not say explicitly what schema is used for validating these contents (for example, whether or not this schema includes components for validating elements in the XHTML namespace), but it seems hard to avoid the conclusion that it must include the components in the schema for schema documents itself. This is a significant burden on implementations (which may not separate structural validation from semantic validation in the way this implies), and it does not deliver a great deal of value to users (there's no particular logic in saying that it's implementation-defined whether XHTML content is validated, but there's a cast-iron guarantee that XSD content will be validated.) Indeed, there's a good usability case to be made for NOT validating XSD content inside annotations - a common programming practice is to comment out code that represents work-in-progress, and there is therefore a user expectation that if you put something in an annotation, the system isn't going to complain if it is invalid. I think that it would therefore be desirable to change the rules to say that the set of schema components used to validate the content of xs:documentation and xs:appInfo is implementation-defined, and need not necessarily include components from the schema for schema documents.
(In reply to comment #0) > 2. As a minimum, there should be a statement somewhere that such elements do > not generate any schema components and do not have to satisfy the (prose) rules > for the XML representation of schema components. This looks ok to me. So +1 for this. > I think that it would therefore be desirable to change the rules to say that > the set of schema components used to validate the content of xs:documentation > and xs:appInfo is implementation-defined, and need not necessarily include > components from the schema for schema documents. This too looks ok to me. Therefore +1 for this as well.
Fwiw, I agree that the spec does not say what happens to XSD elements inside of annotations; I believe it should, but have thought that solving that problem would require a general reworking of the description of the XML mapping rules. The proposal here suggests it can be fixed at low cost; I favor doing so by adopting point 2 in comment 0, unless we discover that some existing implementations do something different. On point 3, I think the analysis of user expectation and convenience is probably correct, but the proposal seems to amount to saying, in effect, that not only is our schema language inadequate to describing the XSD schema documents an XSD validator should accept, but also that we are unable to accept the limits imposed by our vocabulary for specifying wildcard handling. I recognize that strictly speaking, to attack a language because its designers can't or won't use it in certain cases is to be guilty of ad hominem argument -- but in this case my argument is directed not against the language in question, but against a proposal for action by the WG. The principle we should follow here is "eat your own cooking" (or "you made your own bed, now you have to lie in it") -- the rules we set for the handling of annotations have to be expressible using XSD, and should BE expressed using XSD. And I think that means we are stuck with a choice among lax, strict, or skip validation for the children of annotation. Note that a schema author can effectively protect against unwanted validation by wrapping the XSD elements in an element whose type has a SKIP wildcard. That's no comfort for the implementors who interleave validation and verification of XSD elements in ways that are hard to disentangle, when they encounter XSD elements inside annotations that are not so wrapped. But I suspect they'll pretend they didn't see the elements, anyway. Can we construct a simple test so we can check what existing implementations do, before deciding?
Proposal: 1) laxly assess xs:annotation as today, 2) build no schema components cmsmcq proposes several tests: (a) valid and sound declaration, with instance tests to show whether component is built or not, (b) valid but unsound declaration, (c) invalid declaration, (d) invalid declaration wrapped in a skip wildcard.
1) don't generate schema components 2) don't have to satisfy the prose (XML representatin constraints) 3) for schema validation, either a) must satisfy schema for schema validation, but errors in validation in xs:annotation are not required to be reported. b) change s4s wildcard to "skip". c) change s4s to wildcard with "lax" (only works at top level). to be continued.
The WG decided to collect information on how existing processors behave in this area. For Xerces2-J, if I process the following schema document: <xs:schema xmlns:xs ="http://www.w3.org/2001/XMLSchema"> <xs:annotation> <xs:appinfo> <xs:element bad="bad"/> <e>xyz</e> </xs:appinfo> </xs:annotation> <xs:element name="e" type="xs:int"/> </xs:schema> and turn on the "http://apache.org/xml/features/validate-annotations" feature, I get an error complaining the value "xyz" of "e" not being an "xs:int". If I remove the <e>xyz</e> element, then there is no error. Conclusion: Xerces2-J is using the schema being constructed, and not the schema for schemas, when validating annotations.
I would go for David Ezell's 3b) change s4s wildcard to "skip". Job Done. Let's not create rods for peoples' backs. If you want to check it's valid move it out of the annotation.
I have tested Sandy's Schema from comment #5 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10125#c5 With the following implementations: 1) MSXML4.0 SP2 and 2) XMLSpy 2008 I used the following instance document to validate: <?xml version="1.0" encoding="UTF-8"?> <e>123</e> For MSXML4.0 SP2 ---------------- The program loads the Schema Document successfully (ignoring the issues in the xs:annotation element) and validates the instance document correctly. (N.B. I checked behavior when <e>xyz</e> in the instance document, and the validator correctly reports the error). Result: MSXML4.0 SP2 appears (by default) to ignore the contents of <xs:annotation/> For XMLSpy 2008 --------------- With default settings in place, XMLSpy declines to allow validation until I have commented out both the "offending" lines in the schema. Result: XMLSpy 2008 appears (by default) to validate the contents of <xs:annotation/>. Various manipulation of the schema document proves that it will accept an integer value for <e/> inside <xs:annotation/>, and rejects non-integer values.
The original bug report asked: >2. As a minimum, there should be a statement somewhere that such elements do >not generate any schema components and do not have to satisfy the (prose) rules >for the XML representation of schema components. Since XMLSpy 2008 does appear to validate <xs:annotation/>, I ran an additional test (obviously MSXML4.0 SP2 need not be tested again). I used this test schema: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:annotation> <xs:appinfo> <xs:element name="e" type="xs:string"/> <e>abc</e> </xs:appinfo> </xs:annotation> <xs:element name="e" type="xs:int"/> </xs:schema> XMLSpy 2008 rejects this schema document, based on the the fact that "e" doesn't match the correct type. This additional test implies, IMO: 1) we could make a statement that schema omponents need not be generated from definitions/declarations inside <xs:annotation/> 2) the contents of <xs:annotation/> will be laxly validated by the currently active set of schemas, including the S4S. In short, if you use the XSD namespace, the item will be validated. No component will created.
RESOLUTION: Leave the sfsd as it is (lax wildcards for appinfo and documentation) and add prose saying it's implementation-defined what effect invalid annotation elements have on schema component construction. And also adopt Michael Kay's point #2 in the original bug report: 2. As a minimum, there should be a statement somewhere that such elements do not generate any schema components and do not have to satisfy the (prose) rules for the XML representation of schema components.
A wording proposal intended to resolve this issue in line with the instructions in comment 9 is now on the server at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b10125.html (member-only link)
Resolved: adopt the proposal as posted in comment 10.
The change agreed upon in the call of 13 May has now been integrated into the status quo document, so I'm marking this issue resolved. Michael, if you would check the resolution in the status quo document and either reopen or close as appropriate, it would be helpful. Thanks.