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/EML2004DeRose01.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 12:01:48 UTC