Print

Print


This is, as usual, a very cogent point by Syd, and here is some  
corroborating evidence.  If you were reprinting some text you would  
not ordinarily feel any compunction to change page breaks without  
notice. But you would hesitate to drop a sequence of asterisks or  
whatever, although you might replace them with dashes of some sort.

I agree with those who argue that 'divifying' such breaks is not the  
right way to go either. But the <space> element may just be the right  
way to express this very ambiguous form of punctuation or structural  
marking.


On Oct 19, 2007, at 5:06 PM, Syd Bauman wrote:

> I am not yet convinced that <milestone> is an appropriate encoding
> for this sort of thing. A <milestone> (IMHO, and I recognize there
> are others) is not a generic point in the text. Rather, it divides
> the text into two different measurements of the same thing. That is,
> the stuff before the <milestone> is the same as the stuff after (at
> least as far as that which the <milestone> is measuring), only at a
> different navigational point. If it can be argued that <div> is
> appropriate, then what occurs before & after is substantially
> different: they are at different conceptual levels, as it were.
>
> The theory "if the author intended this to be a true division it
> would have been made that way with separate divisions with headers
> and references from the Table of Contents" does not seem correct to
> me. <head> is optional for a reason -- authors don't always use it;
> printers make tables of contents that list only down to a certain
> level of division every day.
>
> So while I would not go so far as to claim <div> is *right*, it
> certainly seems better than <milestone>. If it were really important
> to avoid the effort of using <div> or <floatingText> for some reason
> (like the end is hard to find, perhaps?), I would consider using
> <space>, perhaps with some indication on rend= if there were
> asterisks.
>
>
>> But adding a new suggested value wouldn't affect the schemas (see
>> above).... so I'm happy to consider suggestions for such values
>> (complete with gloss), if they arrive in the next few days.
>
> Actually, new suggested values do affect the schema. But just as with
> re-arranging the order of <attDef>s in an <attList>, they do not
> change the set of documents that are valid against the schema, and
> thus might still slip in between the shutter slats.