Re: Proposed definitions for content, document object, etc.

At 08:12 PM 2000-04-18 -0400, Ian Jacobs wrote:
>Thank you for the comments, Al. My replies preceded by IJ:.
>
>Al Gilman wrote:
>> 
>> At 05:53 PM 2000-04-18 -0400, Ian Jacobs wrote:
>> >Hello,
>> >
>> >As part of resolving issues 207 [1], 211 [2], 226 [3], and 233 [4],
>> >please consider the following definitions. Compare with the
>> >Proposed Recommendation [0].
>> >
>> [...]
>> 
>> >3) Content
>> >
>> >   <BLOCKQUOTE>
>> >   In this specification, the term "content" refers to the
>> >   document object. Some content is designed (by specification)
>> >   for "human consumption". For an HTML document, this includes
>> >   what appears between the start and end tags of elements, and
>> >   the values of some attributes (e.g., alt, title, summary).
>> >   Other content is meant for machines, including the markup
>> >   itself (e.g,. element and attribute names), some attribute
>> >   values (e.g., class, id, lang, src), style sheets, scripts,
>> >   etc.
>> >   </BLOCKQUOTE>
>> 
>> The definition, here, is fine.  The commentary is dangerous.  Some
>> attributes usually are consumed in processing (e.g. stylesheet processing)
>> and do not get included in the displayed view.  But the choice of which
>> properties are processed in that way is an artifact of the chosen view.
>
>Who decides what views are available? I don't think the user
>has the freedom to view content any way he or she chooses. Won't there
>be a limited set of views (e.g., one pre-programmed source view,
>the set of views possible with CSS 1 style sheets, etc.)?

That's the point of the wording of 2.1.  The UA is _not_ required to
construct _arbitrary views_ per user whim.  But no part of the content may
remain inaccessible from all the supported views.  The UA is required to
provide a repertory of views which gets to all properties of all nodes in
the InfoSet.  This is a coverage requirement which is easily met by simple
property lists for the current node.  There is already the requirement to
be able to make any DOM [InfoSet] node current.  The UA can offer fancier
ways to do this.  But it has at least to cover the content.
>
>>  It
>> only seems intrinsic because the association with the dominant view is so
>> strong in what we are used to.
>
>IJ: So to what extent do users determine what content is meant for
>humans? 

This is the same issue as the user style sheets.  The user should have
ultimate control over all such decisions.  The User Agent should taper the
ease of access so that views that are less likely to be needed or more
likely to be confusing are not so near at hand as the others.  But all
content should be exposable by some feasible view.

Nobody else is qualified to make the decision for the user, ultimately.  It
is helpful for the User Agent to employ default views, and layer things so
some things are easier to surface than others.  The unusual cases should
not be the ones that come up by default.  But although the easy should be
easy, the hard should be possible.  

Nothing less constitutes justice.

"Most users won't understand it" is not an acceptable argument.  The
history with HTML is that many users have climbed the learning curve of
HTML document structure because they had the information crowbars available
in some browser.  The ones who need it need to be able to try.  That's why
this is the Web _Accessibility_ Initiative and not the "97% Usability
Initiative."


>This is the essence of issue 207. It's obvious to me that
>the stuff that is designed by specification to be made available to
>users must be available through the UI. It's less obvious to me that
>the rest must be made available directly (i.e., other than through
>the effect caused by processing according to specification).
>
>> The show/hide properties of [logical equivalents of DOM node properties]
>> are given in the HTML specification only as defaults and mostly by custom
>> (show content of unrecognized markup) rather than by specification.  In the
>> unified view of markup languages that the WAI should be sticking to,
>> unstructured content is content and structured content provided as
>> attribute values is content.  All are the basis for constructing views.
>> 
>> Compare with the XML InfoSet document.  Since this abstract view hides
>> syntactic details and parsing, the document applies with very minor changes
>> to HTML as well as to XML.  In other words, the _content_ is even better
>> described in the InfoSet and exposed for programmatic access via the
>> interfaces specified in the DOM.  When the InfoSet document is official, it
>> will be a friendly amendment on the DOM document as defining the 'content'
>> of the document.
>> 
>> Even where there is language that reads like "this content is for display,
>> this for control" in the specifications, this is residual "view chauvinism"
>> of the dominant GUI view of the content.  All content has to be regarded as
>> equally the basis for generating transformed views, as in the generation of
>> transformed views, properties will flow between "display" and "control"
>> roles.
>> 
>> The simple example is the shift characters (for numbers and uppercase) in
>> Braille.  This is control in print, and inline content in Braille.  The
>> status of all other markup language attributes is similar as one considers
>> the full range of transformed views within the goal of "documents that
>> transform gracefully to adapt to user strengths and weaknesses."
>
>> >
>> >6) Source view
>> >
>> >   <BLOCKQUOTE>
>> >   A source view renders all or part of the document
>> >   object in a way that reveals the document object
>> 
>> >   model. Often, a source view presents the document
>> >   object using the syntax of the source markup
>> >   languages.
>> >   </BLOCKQUOTE>
>> >
>> 
>> _Only_ the presentation in the syntax of the markup language used as
>> transfer encoding should be described by the term "source view."  Any other
>> use of this term will simply introduce confusion and distance the document
>> from its readership.
>
>IJ: Amaya's "Show structure" view does not give you the syntax
>of the markup language. But you still get a view of all the elements
>(indented, formatted, etc.). Does this count?

It is not a source view.  It is a better view, for most purposes.  For
those who have used HoTMetaL and not Amaya, the corresponding view there is
called "Tags On."

> 
>> [...]
>> >
>> >8) I propose changing the definition of "view" to be:
>> >
>> >     The term "view" is used in this document
>> >     to describe the purpose of a particular rendering  (e.g.,

>> >     "outline view", "table of contents view", "links view").
>> >
>> 
>> This is a standard concept from data engineering and needs to be applied in
>> the sense which is current in that community, because this is the theory
>> that we need to be applying to presentation diversity.  A view of some
>> information is a particular presentation of a subset of the information
>> selected by a view-filter rule.
>
>IJ: Yes. I started to describe it that way, but pulled back.
>
>>  The concept of views as selection plus
>> presentation of some larger and more abstract information type or instance
>> is standard data engineering and needs to be used in the standard sense
here.
>> 
>> If reference to the Model/View/Controller literature is too political
>> because the documents are Java-centric, then go back to some standard data
>> engineering text (Ullman?).  But don't change definitions on this term.  It
>> needs to be applied here according to what it means, not something we
>> redefine it to.
>
>IJ: Does this work:
>     A view of content is a particular presentation of 
>     a subset of that content. For instance, an "outline view"
>     of an HTML document might be created by filtering out
>     everything but the document's headings.
>

This works for me.  The example helps.  I would probably like there to be a
few references to CS and/or data engineering sources, too.

I may be a little overly hung up on "MVC is _the name of the game_," but
that statement is not too far off base.

Al


>> >NOTES:
>> >
>> > - The same terms (e.g., "content" appear in other W3C
>> >   Recommendations and have different meanings. It's ok to
>> >   define their meaning in our specification to fit our needs.
>> >
>> > - "Content" has been defined so that we don't have to
>> >   use two terms throughout the document. I need to verify
>> >   its usage throughout the document.
>> >
>> > - We should also define "element" and "attribute" separately,
>> >   rather than as part of a definition of "content".
>> >
>> > - This definition of content would not change the meaning
>> >   of checkpoint 2.1. We still need to resolve the scope of
>> >   2.1 in issue 207.
>> 
>> If this means that "what information has to show through the UI" is a
>> separate question from the definition, I fully agree.  The WG has been
>> unclear on this point. But the document that has been shared with the AC
>> says "all content" which on the face of it would say "all the above per
>> [InfoSet] interpretation of the document."
>> 
>> Any retreat from that would constitute a change.
>
>IJ: I agree. I think it's best for the WG to reach consensus on what
>it wants/means, and then to decide how to proceed in the process.
>
>Thanks Al,
>
>   - Ian
> 
>
>> >[0] http://www.w3.org/TR/2000/PR-UAAG10-20000310/#terms
>> >[1] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#207
>> >[2] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#211
>> >[3] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#226
>> >[4] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#233

>> >--
>> >Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>> >Tel:                         +1 831 457-2842
>> >Cell:                        +1 917 450-8783
>> >
>
>-- 
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783
>

Received on Tuesday, 18 April 2000 20:55:43 UTC