RE: A note about the definition of "structure"

This is a fascinating and important discussion.  Last June, Jason White
and I took an action item to propose a new definition of structure, and
I reposted that definition to the list over the weekend.

The key part of the definition was as follows:

"Structure: Structure includes all the parts of a Web resource and the
way they are organized."
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004AprJun/0559.html#star
t

I am not certain that that definition resolves the tension between the
logical or conceptual structure of content and the formal representation
of structure in markup, but at the very least it avoids the circularity
of using the word "structure" in the definition of the term.
John
"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web http://www.utexas.edu/research/accessibility 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Michele Diodati
Sent: Monday, January 17, 2005 6:01 AM
To: w3c-wai-gl@w3.org
Subject: Re: A note about the definition of "structure"



Hi Gregg.

> (...) That makes me think that relationships exist that are not 
> hierarchical.

A not hierarchical relationship can become hierarchical, if we change
our viewpoint, enlarging the base structure of the contents we are
considering to a higher abstraction level. Let us consider a real
example, taken from the Web [1]. In this page, under "The problem types"
header is presented something called "a non-hierarchical structure". It
is in fact an overlapping between two different hierarchical structures:
a first structure made of nested quotes and a second structure made of
Biblical verses. The associated markup, showed in that page, is a
complex compromise, in which two different hierarchical structures are
mixed in a way that let us see a third superimposed, hierarchical
structure. It encompasses both the previous structures, putting them in
a relationship we can call "association". In short, it seems to me that
the presence or the absence of a visible hierarchy depends on the
abstraction level at which we are considering the underlying structure
of the contents.

> We then have several choices
> 
> OPTION 1:
> (...)
> 
> OPTION 2:
> (...)

I prefer option 2, but I think the whole issue needs a deeper
consideration.

> I had trouble however following your comments about separation of 
> content and presentation.  It is true that you use presentation to 
> convey structure. But if you use markup to indicate structure (e.g.
headers) you have
> separated structure from presentation.   The browser then determines
how the
> structure will be presented.
> 
> Also please look closely at the guideline.
> "The Ensure that information, functionality, and structure are 
> separable from presentation." It doesn't say that they can't be 
> confounded - just that they must be separable.  That is - you must be 
> able to derive the information and structure even if you can't view 
> the presentation and must cause the information to be presented in 
> another fashion.  If the structure and information cannot be extracted

> from or is not independently indicated then it will be lost in the 
> re-presentation.
> 
> Is it clearer now what is intended?   Is there a better way to word
this to
> make it clearer?

Your remarks show me clearly which is the crux of the matter. When you
say that structure is separable from presentation, you are thinking - I
suppose - at something as a web page, in which "structure" is associated
with semantic markup (for example XML elements like <author>, <title>,
<description>, etc.) and "presentation" is associated with some
presentational code ("color:#ffff99", etc.).

On the contrary, mi previous post used the words "structure" and
"presentation" in a way absolutely indipendent from markup and markup
languages. This is a very important issue. Note that the two examples of
structure, actually visible at
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=506>, correctly
show relationships between objects in the real world: a book organized
in chapters, paragraphs, etc., and a bicycle, divided into wheels, a
frame, etc. When you think "structure" as related to some markup code,
in my humble opinion you are confusing very dangerously two different
planes: the plane of the real world, to which the contents a web
developer has to logically organize (i.e. structure), trying to make
them accessible according to WCAG 2.0, belong, and the plane of the
markup code, that we use to transfer the organization we can find in the
real world into human readable web pages. If WCAG definition of
"structure" uses real world examples, it isn't justified that guideline
1.3 uses instead the word "structure" in the markup sense. While at code
level we can easily separate structural code from presentational code,
at the real world level we can neither completely separate structure
from contents nor structure from its presentation.

Let us consider a book: while is clear that the headers at the beginning
of each chapter add structure to the contents, you can't eliminate this
visible subdivision without eliminating the content itself of the
headers. On the other side, if you leave the text in the headers,
removing only their formatting (i.e. their presentation), no one will be
able to visually distinguish them from the rest of the text of each
chapter. This demonstrates that, in the real world, structure appears
only through its presentation (and this is the reason why I suggested to
modify GL 1.3, saying that presentation has to be consistent with
structure). Common people ignores the level code, in which a model of
structure can always be present. But accessibility is devoted to common
people. When we speak about contents, structure and presentation, we
should use these words in a sense that is meaningful in the real world.
Or,  if we need sometimes to use some of these words in a specific
technical sense, we have to very clearly distinguish when we are using
"structure" as organization of things and events in the real world, and
when, on the contrary, we are using "structure" as related to semantic
code in the markup of a web page. It seems to me that the two planes are
confused not only in the actual draft of WCAG 2.0, but also in your
remarks to my previous post.

I'm sorry if my argumentations appear not much understandable. Consider
that English is not my mother tongue, and it is rather difficult for me
trying to write complex notions in a foreign language.

Ciao,
Michele

[1]
<http://www.mulberrytech.com/Extreme/Proceedings/html/2004/DeRose01/EML2
004DeRose01.html>
(thanks to Livio Mondini for this link)

----------------------------------
M i c h e l e    D i o d a t i
Via Pian due Torri 86 - 00146 Roma
Tel. 06 5503533 - Fax 06 233212132 
http://www.diodati.org
----------------------------------

Received on Monday, 17 January 2005 13:36:18 UTC