infix separators (vs. exfix wrappers) [was: Re: About XHTML 2.0]

Purging separators is consistent with XML-think.

In that sense, it allows for processing from a smaller set of memes.

On the other hand, separators are not 'impractical,' as their use in
MIME, I think, conclusively demonstrates.

<quote cite=
"http://www.faqs.org/rfcs/rfc2046.html">

5.1. Multipart Media Type

In the case of multipart entities, in which one or more different
sets of data are combined in a single body, a "multipart" media type
field must appear in the entity's header. The body must then contain
one or more body parts, each preceded by a boundary delimiter line,
and the last one followed by a closing boundary delimiter line.

</quote>

And they are not un-semantic, because of the rampant presence of
ungrammatical streams of free association in actual utterance.

The XML Accessibility Guidelines ask for a pure 'container' structure
(eschew separators) but without a well-documented rationale.

http://www.w3.org/TR/xag#cp2_5

The under-developed rationale is along the lines being espoused by
the anti-separator cohort on this thread. To make it more concrete,
one of the most telling comments I have gotten from blind users of
the web is that "I never know what I didn't get." A container model
allows us to give an accounting of "what is there" that lets the user
know if there is something there that is unpenetrable as browsed
through the transformed view in the screen reader.

Be that as it may, I have to disagree with Karl as to what a 'real'
basis for semantics is. There is nothing more real than usage.

The actual usage that best fits an infix separator is the "stream of
unconsciousness" sequence of half-formed and serially-related
phrases. It's not a well-posed sentence, but it is how people think
and speak. In school, the teachers have taught us out of using commas
to separate the segments in such an utterance. So they abuse the
'dash' for a pause that is greater than a comma and less than a full
stop.

This is a collection of utterance that has the topology of a chain, a
streptococcus. Admittedly, we could enter a 'chain' semantic that was
more than 'bag' and less than 'list' for this purpose, and just use
textual order and a suitably classed [by element type or attributes,
no matter] container to convey this semantic.

Separators make the medium more authorable, and closer to natural
utterance. They defeat some of the methods that we would like to
apply to serve the user the author didn't think of. So they add
value, but they require cost; in the form of the utter-er taking a
moment to think about where "what is before the separator" began and
"where what is after the separator" ends. And what each _is_.

[The end point for what follows the separator may even have to be
held in suspense, particularly in encoding speech on the fly as it is
spoken. There are means to deal with all this by holding open a
partial parse tree as the in-stream is marked.]

My posterkid of a separator use case is the filler at the foot of the
Readers' Digest page. This clearly has a 'true' encoding in a
container-ized model. What follows the separator is filler; it is an
exhibit at the magazine level unrelated to the thread of the text
that is flowing around it. So this can be viewed as a sufficient
styling key so that the visual reader of the paper magazine (with the
page frame for further cue) to understand that the little thing after
the separator is an aside. Here if we push back to ask about the
mark-predecessor and the mark-successor, there are good answers to be
had in terms of a tree-and-class model of the document.

But to get that gesture rationalized into continuing story and filler
slug is more work, and we have to work hard on our business case to
get the content contributors to want to care to model their content
that highly.

Each of 'separators' and 'containers only' has its moments of inconvenience.

At least for the person with a disability, who is using a delivery
context that is atypical enough so that the author probably doesn't
much understand the ergonomic tradeoffs in this delivery context, I
suspect that for the lion's share of use cases where the author would
love to inject a separator and be done; there is value added for the
off-nominal-delivery-context user to push back enough to get the
container form fully stated and the parts in it characterized as to
what manner of thing they are or what manner of stuff they contain.

But in defence of the path HTML WG has taken, ISO HTML tried to
impose a fully containerized model and the world yawned.

Al

-- random patch of background in this multi-thread...

At 4:31 PM +0200 5/23/05, Anne van Kesteren wrote:
>Mark Birbeck wrote:
>>>Dropping it would work too. I still haven't seen any use cases that
>>>require this particular empty construct.
>>
>>That doesn't mean there aren't any! Steven gives a number in one of
>>his presentations:
>>
>><http://www.w3.org/2005/Talks/04-19-steven-XHTML2-XForms/>
>>
>>(See about 1/3 of the way down.)
>>
>>The idea is that we need some kind of *semantic* separator. In a
>>navigation list it might separate one group of links from another; in
>>some prose it might be a 'pause' that is more than a new paragraph,
>>but less than a new section or chapter.
>
>Yes, but why does it have to be an empty construct? The use cases 
>you mention could easily be achieved as well using a grouping 
>element that separates the two instances. Using CSS or some other 
>styling language you can tell a voice browser to take a pause or a 
>visual browser to draw a small SVG image between the two section to 
>separate them...
>
>Grouping things in order to separate is more practical than using an 
>empty element construct to split siblings.
>
>
>--
>  Anne van Kesteren
>  <http://annevankesteren.nl/>

Received on Monday, 23 May 2005 21:23:51 UTC