Re: partial implementations

>It is my understanding that it is legal for such applications to
>implement only some of the interfaces defined in DOM.

Depends on how you define "legal."

If you don't implement at least the full "core" DOM, you may not claim to
be  a compliant DOM implementation. You may say that you are a compatable
subset of the DOM APIs, but that's an important distinction.

There are, in fact, a number of such DOM subsets out there. It's a
perfectly reasonable concept; it allows _limited_ reuse of code and skills,
and if it's done properly anything written for the subset can be migrated
to a full DOM though the reverse may not be true. But you owe it to the
user to call this to their attention and explain the differences between
your API and the DOM API.

>For example, few legacy applications could make meaningful use of a
>ProcessingInstruction.

The XML spec says that PIs which aren't meaningful to an application should
be ignored by that application. They are, however, part of the document's
Infoset, and a standard parser should put them into the DOM. You may be
able to argue that the DOM you present to the user is not the parser's
output, but the output of a filtering stage that has discarded the PIs...
but to be a compliant DOM, you have to allow the programmer to explicitly
create and insert PIs, if that's what they want to do. Also, a PI may be
meaningful to _their_ code even it isn't meaningful to the application
itself, so stripping out PIs may impose an unreasonable limitation on how
they apporoach their tasks.



>What should such an application do, for example, in
>createProcessingInstruction? Throw an error, silently return NULL or do
>something entirely different?

If it's a compliant DOM, createProcessingInstruction should return a
ProcessingInstruction node.

If it isn't a full DOM, all bets are off. The DOM Working Group has not yet
defined behavior for partial or subset DOMs,

There has been discussion of introducing the concept of a read-only DOM,
but there seem to be at least four different definitions of how that should
behave and we have not yet reconciled them.


>Also, is DOMException HIERARCHY_REQUEST_ERR thouwn only when trying to
>create a parent-child combination that is disallowed in DOM (such as
>TEXT being parent to ELEMENT), or can it also be thrown when the
>combination is allowed in DOM, but would violate local rules (a DTD or
>the legacy application business logic)?

The former. The DOM does not apply continuous validity checking. DOM Level
3 will introduce ways to ask the Content Model whether an insertion would
or would not be valid, but you'll have to call those explicitly before
doing the insertion rather than having the insertion itself throw an
exception. (Programmers will often know an insertion is acceptable -- or
will be after other changes are made -- and really won't want every
insertion checked every time.)

Of course you can define something derived from the DOM which blocks
inappropriate insertions, if you really want to. But once again, the result
would not be a fully compliant DOM implementation.



______________________________________
Joe Kesselman  / IBM Research

Received on Thursday, 21 September 2000 08:56:07 UTC