W3C home > Mailing lists > Public > www-dom-ts@w3.org > March 2002

Re: Tests that depend on node being inserted for default attributes

From: Curt Arnold <carnold@houston.rr.com>
Date: Mon, 11 Mar 2002 22:35:59 -0600
Message-ID: <009801c1c97f$6896d6f0$a800a8c0@CurtMicron>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:58:46 GMT