Re: Definitions of Element, Text Element, etc.

** Summary

1.  For purposes of definition, the UAAG meaning of the Terms of Art "text
element" and "non-text element" should be "as used in WCAG 1.0, e.g.
Checkpoint
1.1."  Explanatory elaboration on the idea is OK to include so long as it is
clear that the WCAG is the definitive reference in case of questions as to
interpretation.

2.  Still, 'element' is _not_ a Term of Art even 'though the combinations
"text
element" and "non-text element" could be considered Terms of Art.  

3.  However, it would appear that they are terms of the Web Content art, and
_not_ User Agent art.  Help me: is there any requirement on the User Agent to
know what is and is not a "text element" in the checkpoints?  I thought that
the User Agent only needs to know what is, per the markup structure, a
presumed
equivalent for any element (sibling-sub-element in SWITCH in SMIL, ALT for IMG
in HTML, etc.)

** Discussion

1.  Do we have consensus that the purpose of using the terms "text element"
and
"non-text element" is to connect with the concepts of the WCAG, or with
concepts shared with the WCAG?

There is a general rule that should emerge in the WAI coordination-of-usage
practice.  This is that different Working Groups may need different special
meanings ("Terms of Art"), but that we will try to avoid a situation where
subgroups within the WAI use the same terms for different things.  If
different
meanings are needed between different groups, different terms will be used to
denote those meanings.

In this regard, we need to regard the international usage of English as a
virtual Working Group within the WAI for the purpose of applying the above
rule.  If there is a plain English word (in international usage) which
captures
the meanining needed, that should be used in preference to coining a Term of
Art.

--

Let's back off a bit momentarily to review some generalities.  What we need in
the WAI rules, and in particular in the User Agent rules, are things a) that
are effective for the user and b) that are readily doable by the User Agent. 
That is the existential stretch the UAAG lives in.

The problem of how to categorize ASCII graphics illustrates this well.  ASCII
Graphics is composed of text and a particular layout arrangement of the text. 
This could be interpreted as falling within the language "text and
presentation
properties of the text" that I penned.  So that shows the language I penned is
not clear enough in this case.  

The user-centric definition "presentable comprehensibly in all of sight,
sound,
and touch" meets requirement a) of "effective for the user" very well but
requirement b) of "readily doable by the User Agent" less well.  To be readily
doable by the User Agent, ideally it would be stated in terms that are machine
interpretable on inspection of the data of the "document."  

ASCII graphics are not a problem with regard to requirement b), because the
html:pre element that is used to mark them as layout-literal source is a clear
indication that interpreting the content as a _stream_ of characters will
_not_
preserve the comprehensibility of the intended message. 

Note how the WAI-PF working group enters into the plot, here.  It is the
long-range mission of PF to get the format definitions to capture distinctions
about content which are effective for the user in data encodings i.e. markup
which is readily intelligible to machine processing in the User Agent.  In an
ideal world, the format definitions bridge the gap between a) and b).  At
present, they only partially fulfil that mission.  Note in particular Len's
ideas about the potential effectiveness of a dictionary of classes suitable
for
use as values of the class attribute on elements in HTML; and Jon's input to
the XHTML 2.0 requirements that the markup language needs to support machine
discovery of the semantic structure within a document.

Yes, "text element" and "non-text element" are Terms of Art in the UAAG.  On
the other hand, attempting to improve on what the WCAG has done to define
these
Terms of Art without coordinating with WCA WG will only introduce confusion. 
The intent is to import or synchronize with the concepts employed in WCAG
Checkpoint 1.1.  The highest and best glossary entry therefore should make
this
clear; that the definitive source for this usage is as used in the WCAG,
although an informative gloss may be offered in the UAAG to make the document
easier to use.

Because the role adopted by 'element' in the Terms of Art "text element" and
"non-text element" fits well within a general natural-English sense of the
term, 'element' per se is not rendered a Term of Art just because it
appears in
those phrases which are Terms of Art.  The meaning is only special in the
specific combinations noted.  [See details for expansion on how another HTML
document cited in a html:londesc attribute is, in the appropriate user
frame of
observation, "part of the document."]

The term 'element' does not require a definition, although an explanation of
how it has been used may be valuable.  It is good to put entries in the
Glossary where people may mis-read the usage in the volume, even when the
entry
is not absolutely necessary to _define_ the intended sense of a term, or even
if the intended sense of the term is not a Term of Art.

But this probably means we need some way to write entries in the glossary as a
guide to the literal minded on whether a given entry is intended as a
'normative' definition of a Term of Art in the volume or is an 'informative'
comment elaborating on the natural usage employed.

-- details follow

At 12:54 AM 2000-10-22 -0400, Eric Hansen wrote:
>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.
>

AG::

Consider it this way.  A relevant question is "does the use of terminology in
the UAAG connect well with the concepts and terminology expressed in the
WCAG? 


Here both 'equivalent' and 'element' are implicated in the WCAG checkpoint
language "text equivalent for non-text element."  So I think it best we not
try
to close on 'element' entirely until we have checked with GL on how we align
with the ideas there.

>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.
>

AG::

I did not characterize this pervasive ambiguity as a problem.  Just a
situation.  I didn't propose to try to tie 'element' down to either sense,
just
use phrases for clarity where one must be sure to indicate one sense or the
other.

>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.
>

AG::

OK, we are now in Last Call.  No way to separate this glossary entry from the
Last Call process at this point.


>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/dictio
nary><http://www.m-w.com/cgi-bin/dictionar>http://www.m-w.com/cgi-bin/dictio
nar
>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.
>

AG::

I am confused.  The word 'element' by itself is not necessarily subject to
special meaning just because it appears in phrases or compounds which have, in
the compound form, special meaning.  Just because "they," the two compound
phrases, have special meanings, does not mean that either word used in them,
taken alone, should be viewed as having a special meaning.  No?


>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::

I agree.  I am not exactly sure how to word glossary entries to distinguish
restrictive vs. purely illustrative entries.

>
>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::

Yes, those terms are used in some domains to denote roughly similar
constructs.

>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.
>

Yes.  You have outlined the difference clearly.  This is a very important
difference, and one that affects the definition of 'equivalent' as well.

The refrain that we hear over and over from the toolsmiths is "Just tell me
what I have to do."  

The UAAG guidelines properly tie each 'what' to a clear 'why.'  The 'why' has
to do with criterion a) above that it clearly makes a difference in outcomes
for users with disabilities.  But the 'what' language should as much as
possible be clearly "just plain what."   Don't invent mumbo jumbo for 'what'
they need to do when the only thing special is in the 'why.'  The term
'element' should be _descriptive_ of how a document goes together; not why you
need to do this or that with this or that element.  The _prescriptive_ tone
enters in the statement of the whole checkpoint, where the term 'element' used
in stating the 'what' of that checkpoint should be purely _descriptive_ in
tone.

To honor the "just tell me what we need to do" request, we should attempt to
describe the 'what' in language that the reader already understands, with
recourse to Terms of Art only when plain English absolutely fails us.  So far,
in the case of 'element' I am not finding there to be a need for a Term of
Art.  Maybe a glossary entry to clear away the risk that people among the
readership who have encountered 'element' as a syntax-technical term will tend
to read it that way.

What I have stated here is just the argument from effective communication --
i.e. good writing.  There is also the argument from Universal Design that I
have explained earlier to the effect that we should not introduce
access-pecular rules or terms where more general and equally implementable
rules or terms get the job done.  That also suggest that since the general
definition of 'element' fits what we need, we should not put language in the
glossary that makes it appear some special access-peculiar meaning is
needed to
understand what the User Agent implementer has to do.  It's actually simpler
than that.  We want them to immediately grasp how simple it is.

>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. 

AG::

Yes, it is self-consistent to the point of circularity.  No help to the User
Agent implementer in understanding what _they_ have to do, which is make
available user choice (over inclusion in the presented view) concerning
whatever _the markup indicates_ may be an equivalence group.

There is no burden on the UA to know text elements from non-text elements,
actually.  Only to know what is viewed by the format spec as "where the author
should put the other equivalent."

>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."

AG::

Yes, I can see what I said could be misinterpreted as regards ASCII art in PRE
in HTML.

But I would not abandon the bottom-up approach if we needed to define "text
element" and "non-text element."  I would head in the direction of "A text
element is one which can be substantially understood from its character
content
alone, taken as a stream."  The point is to allow expendable fluff like FONT
tags in text elements, but not to include PRE because it requires a rigid
layout constraint to preserve the meaning of those characters.  Something
along
those lines.  But we don't need UAAG definitions for these phrases.  The
distinction is not something that the UAAG requires the User Agent to make
automated decisions about.  Just let the user get at all the equivalents, and
pick what is best for him or her.

>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?

AG::

Since they're not UAAG concepts at all, but WCAG concepts, we should leave the
defining to WCAG or ask WCA WG if we wish a clarification relative to WCAG
1.0.


>
>====
>
>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)?
>

AG::

That doesn't conflict at all with considering it 'part' of the document.  In
the user experience, which is indeed where the WCAG is applying its
terminology
of "non-text element,"
yes, a LONGDESC in a separate file is "part of the document."  

This is the main point about 'element' that bears cleaning up.  That it not
only doesn't mean exactly something marked with a pair of matching tags, it
doesn't have to exactly be in the same file.  The LONGDESC and SRC parts of an
IMG element are alike in this.

But cleaning up, if it is to be done, belongs in the WCAG.  This is a Web
Content notion, not something that is visible in the User Agent processing
directly.

Al

-- all quote from her down

>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/>http://www.hotmail.com.
>
>Share information about yourself, create your own public profile at 
><http://profiles.msn.com/>http://profiles.msn.com.
>

Received on Thursday, 26 October 2000 00:04:49 UTC