Re: More comment on section and h

** summary:

Like the label for a form control, there should be both a nested
version and a threaded version.

The threaded version is more powerful, handles more cases, and the
nested version is more efficient.

[details below]

Al

At 3:06 PM +0200 8/9/06, Daniel Glazman wrote:
>I just cannot believe what I just saw, and I must say I am stupid myself
>since I started commenting on XHTML2 with the first drafts and never
>saw it before...
>
>A section element and the corresponding header have no hierarchical
>relationship... They are siblings. That means it is impossible in an
>editor with a single click without scripting to select the whole
>section, title included. I perfectly understand this was made to
>allow intermediate elements between the section's body and the title,
>but PRECISELY there is a confusion here between section and section
>body.
>That implies that an editor will have to use code to move a section
>before or after another one instead of using the trivial
>select+dragndrop mechanism.
>
>Hey, a document has a root, a title in a head, and a body, but a
>section has no root... What is called 'section' in XHTML2 is in fact
>clearly the old 'secbody' we have seen in old DTDs like CALS (remember?
>There was a world before XML and that world already solved most issues)
>and we miss a real 'section' element.
>
>The section/h model is from my perspective, with my editor implementor's
>hat on, flawed.
>
></Daniel>

Here is a little more evidence sympathetic to what Daniel is saying, from
the consumer side as opposed to the editor-writer perspective.  But
the clean objectification is desired from either perspective.

** DAISY:

compare with <level> and <hd> in the Standard Digital Talking Book.

DTD:
http://www.daisy.org/z3986/2005/dtbook-2005-1.dtd
Spec:
http://www.daisy.org/z3986/2005/z3986-2005.html

** XAG:

Provide a full containment model with chunks of reasonable size
http://www.w3.org/TR/xag#cp2_5

** Roadmap for Accessible Rich Interactive Applications --

In this work we have come across the "tree table" as a structure
pattern of great utility and no-one-tree graph structure.

This view is typical in file-system browsing at present.  There is a
table.  The first column is an index to the rows in the form of a
tree that you can fold or unfold.  The remaining columns give
properties of the entries in the tree-shaped index.  In other words,
the structure of the collection of rows is a tree but the structure
of the collection of columns is a list.  [both could have tree structure,
but most commonly only the collection of rows does.]

In this case, to capture the full semantic structure we have to
thread the first column of cells together with structure outside
the parse tree.  The table structure makes each of these cells
just the first cell in its row; and the cells in the row is the inner loop
of iteration and the rows in the table is the outer loop, as represented
in the XHTML linearization.

So we use IDREF arcs to wire together the semantic graph that doesn't
come for free from the parse.

We don't see any practical (that is deployable, that you can get the
myriad web authors of the World to take up) way to always force
the semantic graphs that one could media-critically analyze out of
a web page's content into one tree that says it all.  So we use one
spanning tree to get all the fragments over the wire, and that tree
plus some additional webbing spun over that basic structure to
capture the rest.

** bottom line.

If <h> nests in <section> then there is an implied rdf:about arc to its
parent for free.  This is a special case of the treatment of <meta>.

If not, there has to be some sort of outside-the-parse arc leading
from one to the other that integrates the sectBody with the sectTitle.

The editor can gather the right collection of pieces from the latter
data graph with only a little more work.

The semantic relationships in what we have to tell people in a web
page form a more general graph than a tree. Any linearization into a
tree is going to ill-serve some of these important relationships.
Once we have treed out the graph for convenience in linearization
over the wire, we have to band-aid the resulting tree with some
cross-connections to preserve the graph semantics.

So both of the above should be admissible:  the heading either is a
child of the container it heads or is connected by an explicit IDREF
arc.  And the nested version saves you characters over the wire.

Al

Received on Wednesday, 9 August 2006 20:23:03 UTC