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/