Hi Anne,
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
I'm not sure what you mean by "a grouping element that separates the two
instances". Do you mean that if you want to separate two things you need to
wrap each of them in an element?
Grouping things in order to separate is more practical than
using an empty element construct to split siblings.
I'm not sure what you mean by "more practical". It's not 'impractical' to
have a separator that's empty, is it?
Regards,
Mark
Mark Birbeck
CE
x-port.net Ltd.
e: Mark.Birbeck (AT) x-port (DOT) net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b:
Download our XForms processor from
http://www.formsPlayer.com/

Adrian wrote:

>However I believe a goal of HTML should be to maximize the number of
>documents it can represent semantically without requiring CSS.

This sentence in itself is something of an oxymoron. "Semantically
without requiring CSS" is a given - CSS only conveys presentation, never
semantics. Yes, HTML must present the semantics of a document, and for
me, that means its structure.

could say we only need <list>, but not <ol>, <uland <nl>, but
>that would reduce the number of documents we could represent with
>simply HTML.

No, one could not say that, because it loses semantic meaning. (That's
ignoring that the <listelement might have a 'type' attribute.) the
other hand, <sephas no semantic meaning that isn't also presented by
putting the two separated parts in their own container. If you believe
that we need more fine-grained control over the type of block, propose
another container.

>CSS, ID and class should not be required to represent a document. They
>are used to enhance a document with additional information; they
>should not be a requirement for most documents. I'm not going to say
>all documents because that would be hard to assert, but for me it's a
>goal.

But I feel very comfortable saying that CSS, ID and class may be
required to *present* a document. CSS might be turned off in a browser,
true, but then this is a shortcoming of the browser. Using this as an
argument for <sepmakes it a presentational element, taken because of
its default presentation. Not good. Do you use an <olover an <ul>
because it is presented with numbers instead of bullet points? do you
use it because the content you have is an ordered list of items? If you
do it for the former reason, you've misunderstood the spirit of HTML.
You're conveying presentation instead of semantics.

><groupdoesn't accomplish this unless it implies there is a seperator
>between each group. If this is the case it has to represent something
>very specific.

<groupimplies that there is a separation between the groups. Does it
imply a visual separation? No, because that's a presentation issue.

Mark Birbeck wrote:

>So, yes, we know that if you have:
>
X
A
B
separator
C
>
>you can make that into:
>
X
Y
A
B
Z
C
>
>That's simple.
>
>But did I say that A and B have a parent of Y? I didn't. Did I say that A
>and B were in the same 'group' as each other? I certainly didn't do that.
>Did I say that A and B are in a different group to C? No. In fact the only
>thing I said was that I want a separator -- I didn't even say what I want to
>separate. Everything else is a layer of semantics that you are trying to
>impose on my document that I did not imply.

Actually, yes, you implied all these things. By separating C from A and
B, you implied that A and B are one group, and C is another. Why else
would they be separated? By using XML, you've implied that every group
has a containing element. Kicking and screaming? Perhaps, but that's how
XML works. If you don't like it, perhaps you shouldn't use a tree-based
markup language.

>It's a indeed, but it does seem to me to be a case of "when you have
>a new hammer belt, you tend to carry your hammer around with you all day".

I thought it was, "when you have a hammer, everything looks like a nail."

Al Gilman wrote:

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

I disagree. The separators in MIME are syntactical constructs. The
semantics of a multipart message are about blocks of data, and the
separators entirely disappear from the semantic representation. And
blocks are best represented, in XML, by containers. The specification
even says so:

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.

Incidently, this very much resembles the implicit closing tags of SGML.
Taking this valid HTML document:

<p>Text
<p>More text
<p>Even more text</p>

This has the very same grammatical representation as a MIME multipart
message. And yet the parse tree is about blocks, not separators.

Laurens Holst wrote:

I think it is good to have a separator element. There are many books
where a chapter contains different perspectives in the story. Those
parts inside a chapter are commonly separated by e.g. a drawing, or
three stars.

But again, you're separating two blocks of content. Why not put them
into blocks instead? Because of the presentation?

Adrian wrote:

>Not all separations will be perspecive changes. Many won't be and it
>gets pretty ugly when you start diving all over.
>
Not all separations will be perspective changes? So they separate some
other kind of blocks. It's still blocks above and below the separator,
and they could and should be wrapped in their own block elements, thus
making the separator useless.

>What may make sense to us here doesn't make sense in another
>language.
>
Can you explain what kind of language you mean? Markup language, natural
language,

>Authors over an amazing number of years have used things like
>* * *
>to add to comprehension of their document. The text above and below
>doesn't necessarily have a commonality, but the author has decided
>that there should be a separation between the two bodies of text. It's
>really not the place of the W3C to say, "you must only seperate things
>into logical groups of the same type that we can understand."
>
Authors over an amazing number of years have used these things to
separate sections of their text, because the readers of sequential text
do not appreciate reading opening and closing text. But that's a
presentation issue. As far as the structure of the document goes, you
have separate blocks.
The W3C defines a language for "Hypertext Documents", and yes, it is the
W3C's place to say what a hypertext document is, and what belongs in it.
See, if you really want to accurately represent an online book, I'm sure
there's an ebook XML language out there. perhaps you can define your
own. Modern browsers all support client-side XSLT, so presentation
should not be an issue. (There's no need for the output of XSLT to be
semantic. That's why it's part of XSL.)

>Taking the following example (lifted from another post):
>
>X
A
B
Separator
C
>
>Moving A and B into a subelement Y and C into a subelement Z
>fundamentally changes the semantics of A, B and C in ways I may not
>want to. For example A, B and C are no longer siblings. Expanding on
>this setup to:
>
>X
Y
A
B
Z
C
>W
D
>
>My intention was that A, B, C and D (say E2) all be the same depth
>that they all be direct children of the class of element that is X and
>W (say E1).
>
Perhaps your intention was wrong? As I said in another post, structure
must be discovered, not defined. I'm sure that once you go from the
abstract to the concrete, you can find a satisfying solution for the
problem.
A, B and C are no longer siblings, but isn't that how it's supposed to
be? After all, you intentionally put a stronger sepration between B and
C than between A and B. It would therefore be inappropriate to say that
A and B have the same relation on the document tree as B and C. B and C
are now first cousins.
D? Well, the most likely problem is that whatever Y is a type of should
also wrap D. And just like that they'r eon the same level again.

>There is no way to address E2 with the child sibling alone. If you
>remove Y and Z and replace it with a seperator it simply becomes E1 >
>E2 which is what I wanted in the first place.
>
E1 * E2
Not much more work, and given the document structure, it is appropriate.

>document structure at
>the section level is taught to be designed before the actual writing
>
And then you must keep to this design. By introducing the <sepelement,
you're trying to break from the boundaries of the design you've given
yourself - clearly a design error.
Designing a document structure, if you want to call it that, means
thinking about what your document contains and how to represent it. It
does not mean making arbitrary decisions on how you want it to be.
Discovering, not creating.

><sectioncannot be used except in overly document structure. If it is
>used for anything else it completely falls apart. Let's say that I
>number the paragraphs in my document so that each paragraph gets a
>number based on its position in the overall document.
>
><section>
<p>I will be 1.1</p>
<p>I will be 1.2</p>
<section>
<p>I will be 1.2.1</p>
<p>I will be 1.2.2</p>
</section>
></section>
>
>I start throwing in sections for other reasons and that falls apart.
>And if you don't like <pimagine it with anything else. You can't
>just throw an extra <olinto a list because you feel like there
>should be a pause.

What are you talking about? Are you claiming I want to insert <section>s
for presentation? No. What we have here is that you give, for your
particular document, additional semantics to <sectionthat do not exist
in the first place, namely the numbering of paragraphs by a scheme you
developed on your own. Let's add a separator to that.

<section>
<p>I will be 1.1</p>
<p>I will be 1.2</p>
<section>
<p>I will be 1.2.1</p>
<p>I will be 1.2.2</p>
<sep/>
<p>I will be 1.2.3</p>
</section>
</section>

Can you explain to me why 1.2.3 is separate form 1.2.1? I can not
imagine any real case where it wouldn't be more appropriate to introduce
another section with another subheading and another numbering level.

taking the <olexample:
<ol>
<li>1</li>
<li>2</li>
<li>3</li>
<sep/>
<li>4</li>
<li>5</li>
</ol>
Show me one situation where you can justify the separator over grouping:
<ol>
<group>
<li>1</li>
<li>2</li>
<li>3</li>
</group>
<group>
<li>4</li>
<li>5</li>
</group>
</ol>

>Here's the issue with depth. All elements of a particular type in a
>document at the same depth should have the same semantic value. And
>while <section class="X"seems like a nice approach that assumes that
>every group can be broken up into class X. It also assumes that I, as
>an author, wish to apply the same <separation /semantics to every
>change in X.
>
You, the document author, decided to give the elements a common class X
in the first place. If you later want to have different separation
semantics for individual parts of the group, you made a mistake earlier,
because clearly, the elements are NT of the same class.

><separation /is useful, lightweight, allows for less typing and is
>in many ways a nice convenience while not detracting at all from the
>semantic web. So what's the problem? It solves lots of problems while
>not causing any and there is a clear use for it. If only all the
>elements in HTML had met that goal.
>
Separation is superfluous. In my opinion, that's enough reason to remove it.
It's also setting a dangerous precedent. Because if we introduce the
empty element <septo separate lightweight blocks, who can argue
against introducing <bigsepto separate heavyweight blocks? what basis?

Henri Sivonen wrote:

<divand class are not a proper substitute. <divand class don't
mean anything to the UA beyond being opaque identifiers you can bind
styles to, and CSS is optional.

<div>, as the name says, places a division. It means that to the UA.
<separatorplaces a separation. The semantic value of the two is
exactly identical (something is a group, separate from the rest), but
<divis easier to work with in processing and more consistent with the
tree model of XML.

Laurens Holst wrote:

As far as CSS is concerned, you can select the elements following a
<separator/element by using the ~ selector (or the element
following it immediately using +). So within its common limitations,
CSS is capable of styling sections around and inbetween separators as
well.

And now apply a border to this selector. Let's just say that the result
will not be exactly what we'd (probably) like it to be.

Sebastian Redl