Re: Checkpoint 2.3

At 3:35 PM +1100 10/28/00, Jason White wrote:
>For this reason, I propose:
>1. that the discussion of checkpoint 2.3 be amplified with further
>explanation and examples; and
>2. that the detailed elaboration of the requirement of logical structure,
>be reserved to the Techniques.

I agree with both of these. I have some concerns about the specifics
below.

>Here is a rough proposal along these lines, which is by no means complete,
>and about which I have some reservations.

Understood.  Hopefully my nitpicking at this will help us firm this
up in a pleasing direction

><dt>2.3 Use markup or a data model to specify the logical structure of
>content.
><dd><p>Note: this allows a diverse variety of presentations, in different
>modalities and on different devices, to be generated automatically through
>the application of style rules. It also facilitates logical navigation of
>the content by the user, a capability which is particularly important in
>voice-based interaction or in circumstances where the content is presented
>on a low-resolution display or braille device.

Hm...  I am beginning to believe that we should standardize each
checkpoint with a <benefit>...</benefit> section which would define
what exactly each checkpoint does.  I very much like the way how you
have been presenting the usefulness of each, which also helps with
increased perception of the _need_ for each checkpoint.

This means that for each checkpoint now we would have to insert a
"reason" clause.  I think that's doable and in fact I think it is
mandatory.  Should this be a separate discussion about document
structure and format?

><p>The details of which structural aspects of the content should be
>expressed in the markup or data model, are set forth in the Techniques
>relevant to each technology [link to 2.0 Techniques]. To provide general
>guidance however, the following is a non-exhaustive list of structural and
>semantic features of content which are considered important:
><ul>
><li>The division of a document into chapters, sections, paragraphs etc;

One point which came out at the DIW is that traditional _written
document_ sections are not universal and so we should be very careful
about stating that division into these _specific_ types of sections
should be avoided.

For example, a typical television show does not have chapters, sections,
and paragraphs; instead, it has scenes, acts, and so on.  An SVG
document has no chapters, sections, or paragraphs, nor does a SMIL
document.

A better idea is:

<li>Divide the document into sections and subsections as appropriate
for the content type.

><li>Lists or groups of related items, for example a bulleted list or a
>group of user interface controls;

This sounds very HTML-specific, almost too much.  Are these meant as
principles or as examples?  The phrasing before the list indicates
principles but some read as examples.

><li>The division of an image into the distinct objects or items depicted
>in it;

How about:

<li>Group related content using markup; as examples, group related
textual concepts in bulleted lists, group related user interface
controls, and group image definitions related to distinct objects.

><li>Headings, labels, titles etc. These should be associated explicitly
>with the information to which they apply, especially in complicated
>structures such as tables.

<li>Explicitly associate labels such as titles, headlines, column
headings, and textual equivalents with the information to which they
apply.

(Basically the same as what you said, just rewritten.)

>  <li>Emphasized text (e.g. as indicated by font changes in a visual
>presentation);

I'm not sure how exactly this should be phrased, or if it's appropriate
beyond HTML/text.

><li>Language changes, especially in multilingual texts where two or more
>langauges occur;

<li>Identify natural language use explicitly and indicate changes in
the natural language of content.

Is the above a checkpoint already?

><li>The use of specialized notations, such as mathematics or computer
>program code;

Also not sure how to quantify this.

></ul> </dd>
>(end of proposal)

Hm.  Thorny.
-- 
Kynn Bartlett <kynn@idyllmtn.com>
http://www.kynn.com/

Received on Saturday, 28 October 2000 03:54:21 UTC