Exporting the DOM

This memo explains a contradiction that I see in the current guidelines --
or at least an interpretation of it -- regarding whether a component that
does _not_ export the DOM can be part of a conformance claim.  I consider
this a 'boundary' problem regarding the subject of the claim (composite user
agent or singular user agent). I think of it as closely associated with what
Jon Gunderson has called the 'line in the sand'.

The basic problem is that the boundary that surrounds the "subject" (short
for 'subject of the claim') is solid and well-defined on one side or segment
but not well-defined on other parts. I don't know if it was always a problem
but its importance seem clear to me as we have allowed "composite user"
agents. I have some ideas for resolution but would like to focus in this
memo mainly on the problem.

The Exclusion of DOM-less Components Within the Subject

If I understand Jon correctly, any component _internal_ to the 'subject'
(i.e., inside the subject) must export the DOM. This came up in the
differing responses of Jon and Charles regarding a question that I posed.
See the excerpt from Charles memo
(http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0360.html )below,
which I have slightly reformatted and labeled with the authors - EH (Eric
Hansen), JRG (Jon Gunderson), and CMN (Charles McCathieNevile).:

<Start Of Reformatted Excerpt>
EH: 
a. No DOM Support in Component of a Composite User Agent

True or False: "It is possible for a user agent that does not implement the
DOM to be a component of a composite user agent that achieves any of the
three levels of claim (single-A, double-A, and triple-A)."
  
JRG: False.  If you do not export the DOM, you cannot comply.
  
CMN: Actually I think it is true that a given component need not export the
DOM so long as the composite agent does.

EH: Answer: True (?). ...
<End Of Reformatted Excerpt>

Defining Some Terms and Concepts

Let us call a component that exports the DOM as a 'DOM component' and a
component that does not export the DOM as a 'DOM-less component'. Thus, the
current document intends that the subject consist _only of DOM components_.
What happens outside the subject is somewhat immaterial because it is
outside the claim. The subject may communicate with external components that
are either DOM components or DOM-less components.

Yet, a problem arises if a user agent developer wants to rely on a DOM-less
internal component to do important work. According to the current document
(or at least what I understand from Jon that it intends), that is not
allowed. It is not possible for a subject to obtain any of the three
conformance levels if it uses a DOM-less component. This problem does not
occur (or does not become apparent) if the subject is 'singular', that is,
that it consists of only one component; the one component is either a DOM
component or a DOM-less component and stands or falls in consequence.

Need for DOM-less Components Within the Subject

Under what circumstances might a developer want to use a DOM-less component
within the subject? One might want to use a DOM-less component within the
subject for _performance reasons_. In W3C FAQ regarding the DOM, we read:

"There is one potential downside to using the DOM: As with any generalized
set of interfaces, the DOM calls can be used to solve a very wide range of
problems, but may not be the optimal solution for any specific problem. The
advantages of interoperability and familiarity to users will more than
compensate for this in many applications, but you will find that some tasks
may call for other interfaces in addition to, or instead of, the DOM. For
example, your application may wish to use custom interfaces internally for
performance reasons, yet be able to import/export/expose its data via the
DOM for convenient access from outside." (http://www.w3.org/DOM/faq.html)

Please note: "... your application may wish to use custom interfaces
internally for performance reasons, yet be able to import/export/expose its
data via the DOM for convenient access from outside."

I could imagine many other things that a user agent developer might want to
do for which performance considerations might be paramount.

DOM-less Components for Rendering

I think that one of the most important things that a user agent developer
might want to do with a DOM-less internal component is to _render content_. 

The current guidelines have many checkpoints that deal with various
renderings that a subject might have. For example, it has many checkpoints
that are applicable if the subject happens to be capable of presenting
certain media types (text, graphics, audio, video), although there is no
checkpoint that requires the subject to be able to render any of them.

It should be noted that while the current guidelines do not _require_
rendering of any particular media type they implicitly require rendering of
_at least one media type_ because there are so many checkpoints that refer
to rendering of content through the user interface, most notably checkpoint
2.1 ("Make all content available through the user interface. [Priority 1]").
If a subject did not render any content to the user interface, it would have
a great number of inapplicable checkpoints. Yet has been no upper limit set
on the number of inapplicable checkpoints. Logically, there is at least an
_implicit_ requirement that a subject must render content in _at least one
way_; if not, it would not meet the definition of 'user agent' ("A user
agent is software that retrieves and _renders_ Web content..." [definition
of 'user agent', emphasis added]).  

I think that for performance or other reasons the developer might want to
render content such as text, graphics, audio, and video using DOM-less
internal components. Are there reasons that multimedia players -- or to
extend the idea of 'player' -- 'graphics players', 'text players', and
'audio players' must be required to be DOM components? Do we as a working
group really want to restrict people from using DOM-less components within
the subject? (Note that these are issues that we run into in rendering
content visually and auditorily, the same issue could be extended to
tactile/Braille renderings but that issue is not as pressing since we
normally think to the braille device as being outside the subject of the
claim.)

The Contradiction

If were to remain firm in saying that each component within the subject must
be a DOM component, then this would mean that a developer who wants to use
DOM-less software to render content must _integrate_ that software into a
DOM component so that is it is literally part of the DOM component_. But
what does one really have to do to make one piece of software, in this case,
a DOM-less content rendering piece of software part of a DOM component so
that it can achieve some level of conformance to the document? How can merge
to the DOM-less content rendering piece into the DOM component? By putting
them in the same physical package? By requiring that they come from the same
vendor? By requiring that they are both put into place by the same
installation routine?

I think that we have already correctly decided our approach to the
installation, maintenance, and upgrading of user agents should be
vendor-neutral, source-neutral approach, and mechanism-independent. That is,
it doesn't matter in the least where components come from or how they are
pieced together. For the purpose of analyzing conformance of a user agent,
it shouldn't matter, for example, whether a component or an entire subject
is pieced together from a hundred different sources (Internet, CD, floppies,
punch-cards, etc.) and vendors or whether it comes one a single CD from a
single vendor. The conformance rating should be the same.

So we end up with a situation in which is contradictory. We want every
component of a subject to be a DOM component because 'DOM-fulness' is the
key attribute that we want to use to determine what we allow within the
subject. Yet for very practical reasons we cannot forbid user agent
developers from incorporating DOM-less 'components' (patches, modules,
programs, etc.) into the subject.

Summary

I think that we need a clear rule for determining what can or should be
allowed within a component or a subject of a claim. I think the document (or
at least an important interpretation of it) has used the rule that 'A
subject of a claim must be composed of one or components, each of which
exports the DOM.' However, I think that this leads to contradiction noted
above.

If we extend Jon's metaphor of 'line in the sand', I think that we need more
than a line. We need a circle or at least a closed loop with a consistent
set of rules for determining what we will allow to within the loop (i.e.,
the component or the subject of the claim). In other word, we need to more
carefully define the characteristics that a subject should have before it
can be seriously in the running for obtaining one of the three conformance
levels.

I think that this can be solved by making clear in the document that the
subject as a whole must export the DOM, but any individual component may not
need to export the DOM. (There may need to be further refinements,
especially as they relate to information going to the user interface that
does not come from the DOM.)
===========================
Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Princeton, NJ 08541
609-734-5615 (Voice)
E-mail: ehansen@ets.org
(W) 609-734-5615 (Voice)
FAX 609-734-1090

Received on Thursday, 7 September 2000 18:52:15 UTC