- From: Eric Hansen <ehansen7@hotmail.com>
- Date: Sun, 22 Oct 2000 00:54:13 EDT
- To: w3c-wai-ua@w3.org
- Cc: ehansen7@hotmail.com, ehansen@ets.org
Definitions of Element, Text Element, etc.
I appreciate Al Gilman's very thoughtful response to my memo "Revision to
the definition of 'Element'".
I think that at the outset, I see resolving the glossary entry for "Element"
as related to but not on the critical path for a resolving of the definition
of "Equivalent". The definition of Equivalent will continue to receive
attention through the Last Call period.
Ian's draft of today (21 October 2000) does not change the entry for
"Element" and that is okay with me.
Several of Al's points do resonate with me. Although I may not grasp the
full significance of all of Al's arguments, I accept at face value his
statement such as: "There is rampant in the community an ambiguity in the
use of 'element' between denoting an actual part of an actual document
[instance] vs. an element type specified (in a DTD or otherwise) for use in
markup to delimit and classify the previous, more concrete sort of
'element.' … Under the circustances there is no reader-safe usage except to
say 'element instance' when one means a specific part of a specific
document, and 'element type' when one specifically means a category of the
above, such as for example all the element types defined in HTML, the
dialect of SGML." In other words some of the problems in the usage of the
term 'element' are ongoing and seemingly pervasive. While I am glad to use a
discussion of equivalent to illuminate these important issues, at the same
time I do not want the full burden for resolving such issues to be placed
upon the definition of equivalent. The problems that Al cites did not
originate with 'equivalent' nor should the definition of equivalent be
obliged to definitively resolve all these issue before moving forward.
In trying to at least partially separate the resolution of 'element' issues
from 'equivalent' issues, I am not saying that his memo unduly entwined
them. (Indeed, it was I who 'entwined' them in suggesting that the
definition of 'element' be modified to better reflect usage in terms such as
'text element'!) I mainly want to alert readers that in my view, the basic
adequacy of the definition of 'equivalent' does not hinge upon further
clarification of issues surrounding the glossary entry for 'element.'
Furthermore, I do not think that this issue should in any way affect plans
for going to Last Call. I think that we have a very narrow window of
opportunity to improve the definition of "Element" before going to Last
Call. I think that it would be nice to clarify things a bit if we can, but
if we can't, then there is still no reason not to proceed.
Below I have made some notes. Sections beginning with "AG:" are comments of
Al Gilman and those beginning with "EH:" are those of Eric Hansen.
====
From: Al Gilman (asgilman@iamdigex.net)
Date: Fri, Oct 20 2000
To: "UA List (E-mail)" <w3c-wai-ua@w3.org>
Subject: Re: Revision to the definition of 'Element'
AG:
1. Why is this conversation happening now? Are we making changes like this
to the PR draft?
2. There is no need for a Term of Art, here, because the sense of
'element' in the WCAG provisions that are the basis for the UAAG provisions
in question
is a natural English sense of "a constituent part" [c.f.
<<http://www.m-w.com/cgi-bin/dictionary>http://www.m-w.com/cgi-bin/dictionar
y>, search on 'element,' select sense #2].
EH:
I see that you believe that a special meaning ('Term of Art') is not (or
should not) be necessary in the glossary entry for 'element' in order to
cover 'text element' and 'non-text element'.
It seems clear to me that these terms do (and should) have specific
meanings, which are already reflected in other parts of the UAAG document.
As an aside, I think it worth noting that even if the usage of text element
and non-text element _did_ fit neatly within the "natural English sense of
'a constituent part'", that would not be a sufficient reason to exclude such
a meaning (and/or usage) from the glossary. (I am not sure whether you were
asserting that it would be sufficient reason.) If the term is _only_ used in
its 'natural English sense', then there might be grounds for excluding the
term. However, if the document uses _more than one_ meaning, only one
meaning of which is the natural English sense, then that is _all the more_
reason to include the natural English meaning along with the other meaning
or meanings of the term. Otherwise one would not even know that the term
_could_ be understand in its natural English usage.
AG:
That said, Let me clear up the usage in this area just a bit.
There is rampant in the community an ambiguity in the use of 'element'
between denoting an actual part of an actual document [instance] vs. an
element type specified (in a DTD or otherwise) for use in markup to delimit
and classify the previous, more concrete sort of 'element.' To make the
distinction clear, one could use 'element' and 'element type' but often
'element' gets reassigned and we wind up talking about 'element instance'
and 'element.' Under the circustances there is no reader-safe usage except
to say 'element instance' when one means a specific part of a specific
document, and 'element type' when one specifically means a category of the
above, such as for example all the
element types defined in HTML, the dialect of SGML.
EH:
I agree that the terms 'element' and 'content' are used in many different
ways and that there is a lot ambiguity about whether one is talking about
instances or types.
AG:
However: the sense of 'element' in the WCAG 1.0 discussion of "text
equivalents for non-text elements" is the natural English sense of "a
constituent part" and not the syntax-technical sense of "an instance of a
markup construct defined as an element in the formal specification of the
markup dialect."
EH:
I agree that the usage of 'element' in the terms 'text element' and
'non-text element' are _not_ synonymous with "the syntax-technical sense of
'an instance of a markup construct defined as an element in the formal
specification of the markup dialect.'" I think that the fact that they are
not synonymous can be analyzed on several levels, but at one basic level, I
know of no markup language that intentionally maps to these constructs,
except at the barest level. That said, I think that we need to realize that
we are essentially in our infancy in terms of defining markup languages that
will support accessibility concepts. The availability of "alt" attributes in
HTML and other languages is just a small but important step toward that end
goal. I would hasten to remind us that I think the WCAG and UAAG has
properly tried to frame their specifications such that they are not focused
on just one language (e.g., HTML) but that they are intended, as much as
possible, for implementation in various language environments. Therefore, it
is not surprising that the UAAG usage of terms like text element and
non-text element do not necessarily map exactly or completely to any
existing markup language.
As to how well the usage of 'element' in terms 'text element' and 'non-text
element' is captured by the notion of 'a constituent part', I have some
concerns that I will explain later in this memo.
AG:
The fact that it is not the technical sense may bear mentioning, but this is
a warning, not a 'definition.'
EH:
I think that this is a very good reminder that the glossary can alert the
reader to different usages without necessarily claiming to provide specific
_definitions_. I think that this comment may point the way to a
clarification of the UAAG glossary entry for "element." I use this approach
at the end of this memo.
AG:
Note: The phrase 'logical construct' is much too broad as it includes
categories such as 'connective' or 'preposition' or 'reference' which are
never referred to as 'elements' in the disucssions in the WAI documents.
The category of 'logical constructs' that we use 'element' for is 'element
types.'
There is no need to fall back any further into looser categories.
EH:
Your comment about the phrase 'logical construct' as being 'too broad' seems
to make some sense though I don't know what others have intended by the term
and therefore I don't know what we would lose by not using the phrase.
AG:
Warning 1: It is important to understand the design elements of a web page
as including the actual image embedded in the document by an IMG element in
the markup language, although regarding the document as just the HTML text
of the source one would find that only a reference to the image is preseant
in the IMG element in the HTML file.
Warning 2: It is perfectly legitimate, however, for someone to talk about
header font and type color scheme as elements of a company's branding
scheme.
This is a pattern of properties that is not a document part and it is not
represented by an XML or SGML element type definition in the formal
organization of the markup language. But it can be said in one of our
documents without breaking our usage because it is just another example of
the
plain English sense of 'element.' The key is that it is made clear in the
context what this syndrome of presentation properties is an element (i.e.
part
of component) _of_.
There was question as to whether 'element' refers to a type of content. Not
quite. The point is that all the named elements in HTML and other SGML and
XML applications _do_ have connotations as to categories that the content
range so marked falls within. But these categories are often heuristic,
that is to say not machine-interpretable without the aid of a
natural-language-capable human.
So although one of the common senses of 'element' is 'element type,' and
'element type' does contain information about what kind of stuff is in
there, an 'element type' is not a kind of stuff, but rather a kind of part
which has restrictions as to the kind of stuff one will find in it (and its
role in the context).
EH:
I think that I hear you saying that the element type is what in some domains
might be called a "class" or "abstract class" or "abstract entity".
AG:
Webster lists "a constituent part" as the second sense of 'element' and that
is the generic sense used throughout UAAG and the rest of the WAI
literature. It is inadvisable to try to give a reserved meaning to
'element' in the UAAG as a whole. If you want to make the usage more
precise in various places, it could be useful to introduce glossary entries
for "element instance" and "element type" and place a note in the glossary
indicating that 'element' has been used for either of these or the Webster
sense "a constituent part" interchangeable where it is clear from the
context which of these is intended. We should
endeavor, and say we have so tried, to use "element instance" or
respectively" element type" where the distinction is important.
Note: there is no need to be concerned about how 'element' is defined as
used in the glossary entry for "text element." The introduction of "text
element" in the glossary is gratuitous. Searching for this phrase
encounters no hits until it appears in the glossary. It is a self-requiring
exercise in unnecessary definition of terms. However, if you wish to
understand what "text element" and "non-text element" should mean in the
satisfaction of WCAG, please consider the following nominations:
* A _text element_ is a constituent part of the document (i.e. in the
general, not syntax-technical sense) whose content is entirely composed of
text and properties of that text.
* A _non-text element_ is a constituent part of the document (same proviso)
that is not a text element and cannot be reasonably decomposed into
constituent parts some of which are text elements and some are not.
EH:
It is obvious that there are differences between the definitions you propose
and those that are found in UAAG (29 September 2000).
1. Accessibility Focus: Preeminent versus Implied. A very important
difference between the UAAG definition of text element and your proposal for
the term is that the UAAG definition has its _accessibility capability_ as
its _preeminent_ characteristic, even its defining characteristic, whereas
in your definition of the accessibility capability is merely _implied_.
Specifically, the UAAG definition text element has as its defining
characteristic its accessibility features, that is, being understandable
when output as visually displayed text, synthesized speech, and braille to
particular disability groups who find those information delivery modes
helpful (deaf, blind, deaf-blind, respectively). On the other hand, your
definition does not even mention any accessibility feature, though some
accessibility is implied by its reference to "text", which some readers
should realize can have good accessibility benefits.
The UAAG definitions of text element and non-text element provide a clear
minimal standard that is directly tied to the most fundamental barriers to
Web access of which we are aware and to what we believe it takes to remove
those barriers. Today almost all Web content relies on senses of sight
and/or hearing and the UAAG definitions of text element and non-text element
are directly tied to modes of display that are helpful to people whose
disabilities impair their sight, hearing, or both.
2. Compatibility with Checkpoint 1.1 of WCAG 1.0: High versus Low
The UAAG definitions of text element and non-text element are highly
compatible with WCAG 1.0 checkpoint 1.1 whereas your definitions have
critical incompatibilities. WCAG 1.0 checkpoint 1.1 requires authors to
"Provide a text equivalent for every non-text element" and then provides a
list of what apparently count as "non-text elements". This checkpoint is
perfectly understandable in the context of the UAAG definitions of text
element and non-text element. That is, the reason that we _require_ text
equivalents -- which _are_ text elements -- for every non-text element is
because non-text elements _fail_ to be understandable in any of those three
important modes. The text equivalents directly fill the need because, as
text elements, they _are_ understandable in those three modes. It fits
together extremely well. On the other hand, your proposed definition of
non-text element contradicts important parts the list of non-text elements
in checkpoint 1.1. Specifically, if I understand your proposals, note that
some of the "non-text elements" in checkpoint 1.1, notably ascii art and
scripts, would be counted as "text elements". Good definitions of text
element and non-text element should _not_ allow an element to be both a text
element and non-text element _at the same time_. Based on this issue alone,
I cannot accept the idea that your proposals are closer than the UAAG
definitions are to "what 'text element' and 'non-text element' should mean
in the satisfaction of WCAG."
I believe that the UAAG definitions of 'text element' and 'non-text element'
are highly compatible with and supportive of the direction set by WCAG 1.0.
In deciding between the UAAG definitions and Al's proposed definitions, I
think one needs to ask oneself the following two questions: (1) Do I want my
core concepts such as 'text element' and 'non-text element' to be directly
tied to the presence of or absence of critical accessibility features or do
I want a looser connection to accessibility? and (2) Do I want definitions
that are compatible with WCAG 1.0 checkpoint 1.1 or do I want definitions
that contradict some of the provisions of checkpoint 1.1?
====
I would like to highlight a very positive contribution of Al's proposed
definitions. In his definition of non-text element he refers to or at least
alludes to the possibility of non-text elements being decomposed into
smaller elements, some of which may be text elements and others of which may
be non-text elements. In addressing such issues, Al is, I believe dealing
with critical issues such as the levels of granularity at which these
elements can or must operate and whether elements can include elements.
These issues are important issues that, if not resolved by specifications
must be resolved by developers of Web content and by developers of user
agents themselves. Dealing with such issues is an inherent part of
implementing any accessibility framework in software. I have previously
brought up issues and suggestions along these lines but there is little if
anything in UAAG that directly addresses this issue. Nevertheless, the
absence of specifications on such issues may not be all that bad because
exactly how one resolves those issues may depend on the environment in which
one is operating. My point here is that issues such as element granularity
and the extent to which elements may include other elements are important
issues. They are issues that need to be addressed but I don't think that
they need to be addressed in UAAG. Indeed, resolving such issues at least on
the content creation end of things is something more within the purview of
WCAG than of UAAG.
AG:
The main reason for putting a glossary entry in the document is that readers
of the content may be markup-language-literate and will need to be warned
that the syntax-technical sense is not what is intended [in the WCAG
language]. Note that since the issue here is echoing the WCAG requirement,
the appropriate way to get usage clarification would be to ask the WCA WG
for an interpretation of the document.
All of this is dependent of understanding that 'part' in the above indicates
something which contains a subset of the content of the document, _and_
would be recognizable by a reasonable user as a thing in its own right.
Al
EH:
I have some concerns what I think Al is suggesting about an element as being
'part' of a document. I think that in terms of the accessibility function of
an element, it makes no difference whether all its parts are in one document
or a hundred documents. It is the output, the interface with the user, that
matters most of all. Why not view Web content as an "application" as some
have advocated and allow the fragments of a text element (or any element) to
be drawn from anywhere in the application (or even beyond the application)?
I submit that at the basic definition of text element and non-text element
should make no assumptions about implementation details such as how elements
are produced, where elements and their parts are stored, and the size of
elements.
I realize that as a practical matter some standards need to be established
but I believe that we need to very judicious about specifying implementation
details. We think of the Web one way now and it may be something very
different in five years. By over-specifying implementation details we risk
having our specifications become prematurely obsolete.
I think that when implementation details must be specified for practical
concerns, then, whenever possible, they should be qualified by terms such
as: "This type of element (or this feature) is _ordinarily_ implemented in
such as such a way." Or we can specifically state "This is how it is
implemented in an HTML environment."
This is what the UAAG does for the definition of text element. The basic
definition of says nothing about a text element's storage location, how it
was produced, or what it looks like inside. It is judged merely on its
output characteristics.
Then it goes on to make a few judicious comments about implementation. For
example, it says, "In general, text elements are composed of text (i.e., a
sequence of characters)." (definition of "Text content", etc.). In other
words it says that very little bit about the internals of text elements.
Personally, I would prefer to say simply, "A text element outputs text
characters", but I think that this concession to an implementation detail is
okay.
The definition of Equivalent takes the same approach. It provides the basic
definition Equivalent and then it goes on to say how it is implement in HTML
and SMIL without trying to establish how it _should or must_ be implemented
in general.
Therefore, I do not support saying that the content for an element (either
text or non-text) must reside in a single "page." I think that is too
limiting. There may be specific implementations where that approach must be
taken, but I don't think that such as detail belongs in this version of
UAAG. I think that such a limiting implementation detail should not be
established without involving WCAG and even if it became established I would
advocate limited its scope to certain implementations.
Possible Change
We can either leave the glossary entry alone or we can follow a suggestion
to which Al may have been alluding. That is, we could modify the definition
simply to signal that there are other usages of "element" that may not fit
neatly into the other categories.
New (21 October 2000):
"Element This document uses the term "element" both in the XML sense (an
element is a syntactic construct as described in the XML 1.0 specification
[XML], section 3) and more generally to mean a type of content (such as
video or sound) or a logical construct (such as a header or list). In
addition, the document uses the term in the context of "text element" and
"non-text element" (see definition of 'Text content, [etc.]).
Comment 1:
This approach is very conservative. It simply signals the existence of
another usage but does not attempt to define it. I think that this is the
most reasonable approach at this point.
Comment 2:
I have not changed the reference to "logical construct" since I do not know
removing will break anything.
For your information and for comparison, here is my 20 October 2000 memo:
At 05:15 PM 2000-10-20 -0400, Hansen, Eric wrote:
>I wanted to make sure that our definition of "Element" adequately covers
>our
>usage in definitions such as "Text element". Is our usage as a "logical
>construct" or something else? I think it as a "unit of content" rather than
>necessarily being tied to particular "type of content". For example, a
>"multimedia presentation" might be considered an element, but also might
>its
>visual track or even a text equivalent of a visual track might be
>considered
>"elements".
>
>Your comments welcome.
>
>Old (29 September 2000):
>
>"Element This document uses the term "element" both in the XML sense (an
>element is a syntactic construct as described in the XML 1.0 specification
>[XML], section 3) and more generally to mean a type of content (such as
>video or sound) or a logical construct (such as a header or list)."
>
>New:
>
>"Element This document uses the term "element" both in the XML sense (an
>element is a syntactic construct as described in the XML 1.0 specification
>[XML], section 3) and more generally to mean a unit of content (text
>element
>or non-text element) or a logical construct (such as a header or list)."
>
><END OF MEMO>
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
Received on Sunday, 22 October 2000 00:54:46 UTC