Re: Exporting the DOM

Eric,
My original response was wrong.  The composite of the components that claim 
conformance must export at least the author supplied context through the 
dom for HTML and XML based markup languages.  Each component of in 
collection of components in the claim does not need to support the dom, but 
the combination of the components must.  In the future the DOM may support 
exporting user interface information.

Jon



At 06:53 PM 9/7/2000 -0400, Hansen, Eric wrote:
>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

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Friday, 8 September 2000 13:11:36 UTC