Re: isSupported12.xml

> > [mb]  I'm not following you here.
>
> [ca]
> An implementation is not allowed to purposefully throw an exception for
conditions that aren't explicitly defined.  There is a general allowance
that run-time errors, such as memory exhaustion and
> null pointer references, can occur.  However, if a method says "No
Exceptions" then it shouldn't purposefully throw an exception.  The expected
behavior of isSupported when presented with an
> unrecognized or unusual feature is to return false.  Throwing an
exception, however well-intended, is not conformant.
>
> Putting a wacky feature in the test list is a check that the implementor
didn't decide to throw an exception.
>

I think we are saying the same thing -- sure, checking for an XML Name which
could be defined as a set of extension features
could be added, and it should return either true or false -- you could also
check for a wacky name, if it were an XML Name,
then it would return false, presumably, but I don't think that it a good
substitution for tests for valid names.  As far as throwing
exceptions, when I see that there are No Exceptions, I read that as no
DOMExceptions -- are you talking about something else?

>
> > [mb] I disagree.  The spec clearly states that the extended
> > interfaces are optional --
>
> [ca]
> However, to get to the section of the test that checks isSupported(), this
particular test (and most if not all of our other tests) loads an XML
document.  This test presupposes support for XML as
> part of its minimal condition to run.  We have not been putting that
minimum requirement into the test prolog, however we will need to do so
eventually.  When that is placed in the prolog, this test
> would not run unless the implementation.hasFeature("XML") returned true.
>
> So with the precondition that this test only runs on implementations where
implementation.hasFeature("XML"), then isSupported("XML") should also return
true.
>
>

[mb] I think you are missing the point.  This part of the message has
nothing to do with isSupported -- rather, when researching what was meant by
the feature
"XML", how is it different from "CORE", and what is really required,
according to the spec, we noted that "XML" is defined to be the set of
extended interfaces -
in particular, CDATASection, Entity, EntityReference, DocumentType,
ProcessingInstruction, and Notation.  I'm suggesting that all of these tests
for extended
interfaces should be moved to a separate section, other than core, and that
we should categorize the tests according to the features that are defined in
the spec,
rather than putting both fundamental and extended tests under core.  Then,
our directory structure maps more intuitively to the spec than it does
currently.

--Mary

Received on Thursday, 25 October 2001 17:06:33 UTC