- From: Curt Arnold <carnold@houston.rr.com>
- Date: Mon, 11 Mar 2002 22:35:59 -0600
- To: <www-dom-ts@w3.org>
I've got a set of statements at the bottom of this message that I'd like to have confirmed (a clear yes, or an equally brief reformulation) so we can close this issue. But first some digression: Phillippe Le Hegaret wrote: > Even if the test suite has a way to determine if the underlying XML > processor is validating or not, generating an error on the DOM > implementation may be inappropriate if the default attribute is not > there since it can be a problem with the XML processor. Now, if we have > a way to ensure that the XML processor did the right thing underneath, > then it is certainly an error. One solution would be to say in the > documentation that the DOM test suite assumes that the XML processor is > XML 1.0 conformant (and points them to the XML test suite). Therefore, > not having the foo attribute would be an error. Any test could be undermined by the hardware, operating system, the programming language, the compiler or stray gamma rays. The fact that we can't ensure that every layer below the layer under test is working flawlessly, doesn't eliminate the value of testing a particular layer with an implicit trust of the lower layers. That trust might be violated and the analysis of the test failure should properly identify who was at fault. >One solution would be to say in the >documentation that the DOM test suite assumes that the XML processor is >XML 1.0 conformant (and points them to the XML test suite). Therefore, >not having the foo attribute would be an error. That seems to be the only solution. Since most DOM implementations are typically tightly bound to a particular parser, an application developer should not care if the source of the conformance failure is a flaw in the parser or the DOM implementation. Either way, his expectations were violated and it should be of no interest to him if they flaw was due to the parser implementation team at Example, Inc. or the DOM implementation team at Example, Inc. >> If the behavior was never required, then the tests should be deprecated. >The behavior was never required by the XML specification at the first >place. The DOM L1 spec errata: In addition, if there are known attributes with default values, Attr nodes representing them are automatically created and attached to the element. The authors of the original NIST tests and multiple Java implementations (possibly to pass the NIST tests) interpreted this to require that the loading processor provide more than the minimum information required for XML 1.0 conformance, that the underlying parser must provide default values even when not validating to produce a conformant DOM tree. That is they interpreted "known" as "specified" or "knowable" instead of "required to be provided by an XML 1.0 conformant processor" For example, see http://xml.apache.org/xerces-j/faq-write.html#faq-7 where they list defaulting of attributes as being required for both validating and non-validating modes of operation. This is a FAQ since many people asked why Xerces loaded the external subset even when not validating. The standard answer was that it was required to produce default attributes believed (erroneously) to be required in all circumstances by the DOM spec. Though that interpretation was apparently flawed (acceptible, but beyond the minimum required of a conformant processor), it was reasonable interpretation by experienced practitioners. I think that is worthy of clearer wording in an errata and/or later revisions. ---------------- I'd like to have a affirmation or rejection of each of the following statements: Providing Attr nodes for default attributes specified in an external subset is required when loading a document using a validating processor. Providing Attr nodes for default attributes specified in an internal subset is required when loading a document using any processor. Providing Attr nodes for default attributes specified in an external or internal subset is never prohibited. The initial form of the default attribute tests* demanded behavior that was optional for non-validating parsers and therefore were not valid conformance tests. The current form of the default attribute tests (which mark the tests as not applicable to non-validating parsers) only demands required behavior and are valid conformance tests. * attrdefaultvalue.xml, attrnotspecifiedvalue.xml, attrspecifiedvalueremove.xml, documentcreateelementdefaultattr.xml, elementremoveattribute.xml, elementremoveattributerestoredefaultvalue.xml, elementretrieveallattributes.xml, namednodemapremovenameditem.xml, namednodemapremovenameditemgetvalue.xml
Received on Monday, 11 March 2002 23:36:04 UTC