[tei-council] proposed re-org of div wrapping

Thu Apr 19 17:49:38 EDT 2007

Syd Bauman wrote:
>> Eh? Hang on! where did this postscript element come from? is there
>> a sffr or trac item about it? 
>>     
>
> IIRC, you were the one who said that while we can publish P5 1.0
> without a letters & memos module, not having a method for encoding
> postscripts would be an embarrassment.
>   
Did I really. But that doesn't actually answer my question, does it?

>
>   
>> why do you think the content model of div is broken?
>>     
>
> Because <head> and <opener> are allowed at the bottom where they
> shouldn't be.
>
>   
It depends what you mean by "bottom". If you have a div that has only a 
head in it, that's OK in my book,  even tho the head is at the bottom. I 
assume that what you're objecting to is <div><p/><head/></div> which i 
agree looks decidedly broken. If you have a proposed revision of the 
divWrapper bit of the class system which provides a solution to this 
then so much the better: let's see it properly worked out and tested.

>   
>>> model.divTop = head opener salute epigraph
>>> model.divBottom = closed signed trailer ps
>>> model.divWrapper = argument byline dateline docAuthor docDate 
>>>       
>> this is not far from what we used to have, before (in Oxford) we
>> decided to make divWrapper.bottom a subclass of divWrapper, and
>> make divWrapper a combination of the old divTop and divBottom
>> Why are you revisiting this issue?
>>     
>
> You are correct, it is quite similar. I'm revisiting it because as
> implemented bottom-in-Wrapper turns out not to work.[1] I wonder if
> it wouldn't be better to use different names, though.
> model.div.start, model.div.end?
>
>   
let's stick with top and bottom for the moment -- we might want start 
and end for horseification purposes one day.

> BTW, the proposal I sketched out was to keep the three models
> separate, but it might be cleaner to have only 2 classes that get
> referenced from content models. I.e., instead of what I sketched out,
> have
>
> model.divTop = model.divWrapper head opener salute epigraph
> model.divBottom = model.divWrapper closed signed trailer ps
> model.divWrapper = argument byline dateline docAuthor docDate 
>
>   

I dont understand this: once a class is defined it can be used anywhere. 
Or are you proposing macros here?

>> divGen is supposed to behave just like a div, except that its
>> content can be generated. If it's a div it has to be able to have
>> divWrapper elements inside it. It's a convenience for the encoder
>> if the divWrapper elements can be explicitly attached to the divGen
>> rather than generated along with the content. I don't think it's
>> anything to do with <index> particularly.
>>     
>
> Hmmm ... I suppose I can see how it might be more convenient to have
> some of the stuff surrounding the generated content in the source
> XML. 
>
>   <divGen type="stats">
>     <head>Statistics</head>
>   </divGen>
>
> Although it's a little harder to see the case for <argument>,
> <epigraph>, or <salute>, let's presume there is a case. But if so,
> why not <closed>, <signed>, or <trailer>?
>   

you mean, why does divGen contain divWrapper but not divWrapper.bottom? 
fair question, and the answer is probably just an oversight. when you've 
sorted the classes out....

>  Why not just
> ditch <divGen> entirely, and advise people to use 
>   <div type="generatedIndex"/>
> or whatever? Or perhaps we can add <div> to att.typed (taking type=
> out of att.divLike), so that there's a subtype=:
>   <div type="generated" subtype="index"/>
>   
Plausible. But I still  think a <divGen> really is quite a different 
sort of beast from a <div> all the same.

> The semantics of the suggested value "generated" could be applied to
> other elements as well. <ab> jumps to mind, but I chuckle when I
> think what it means to see <lg type="generated" subtype="sonnet"> :-)
>
>   
That way madness lies.