Print

Print


Dear David

Thanks for this. You're quite right in your analysis: the content models 
of un-numbered and numbered divs do differ in this way in the current 
release. I agree with you that they should behave consistently, and 
therefore this is an error. There are two possible ways of resolving it: 
one is to rethink the change made to <div>, and the other is to apply 
the same change to the numbered divs. The latter is obviously simple and 
straightforward, and I am therefore planning to do it. But for the sake 
of completeness, and because I know there is some disquiet about the 
change to <div>,  let me sketch out the alternative. The content model 
for div/divN looks complex, but the essence of it is something like this

optionalFlummery*,
((seriousStuff+, moreDivs*) | (moreDivs)+),
optionalFlummery*

which works fine as long as "seriousStuff" and "optionalFlummery" form a 
disjoint set -- i.e. you don't have any element which is a candidate for 
both. It also works fine as long as you are sure you will always have at 
least one bit of "seriousStuff".

However, as a result of oft repeated requests, we recently decided to 
move the <note> element out of the "seriousStuff" category and into the 
"optionalFlummery": that is, we decided that <note> should be made a 
member of model.global, and taken out out of model.component. (Obviously 
it couldn't stay in both classes). And we also noticed that maybe it 
wasn't such a bad idea to permit an empty div, or one that contained 
nothing but flummery.

Hence the decision to make everything after the initial flummery 
optional. While I am willing to believe that it might be possible to 
come up with an even more complicated content model, and a further 
complication of the class system to enforce the "divs must have some non 
flummery content" rule, (a) I don't have the time or energy right now 
(b) I am not convinced that such a rule is either necessary or correct.

Note that simply removing the optionality from the content model of div, 
while it would make the two consistent, would mean that lots of existing 
documents become invalid until we work out how to make <note> global in 
appearance without its being a member of the model.global class -- a 
particular circle I have no desire to square.

So I plan, as aforesaid, to add the optionality into the divN elements 
as well. If someone comes up with a better cunning plan, I'd be glad to 
revisit the issue, of course.

Lou





  David Sewell wrote:
> The following markup is valid in TEI P4 and releases of P5 prior
> to 0.6, but with 0.6 it registers as invalid:
> 
>   <div1>
>     <note>Note 1.</note>
>     <note>Note 2.</note>
>   </div1>
> 
> (where "div1" can be any numbered div). But it remains valid if an
> unnumbered <div> is used instead of a numbered one.
> 
> Looking at the content models for <div> and <div1> in the
> current documentation:
> 
>   http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-div.html
>   http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-div1.html
> 
> it's obvious where the problem is: <div> is defined as zero or more of
>    ( model.divWrapper | model.global )
> followed by  zero or one of the rest of the content model.  But <divN>
> is defined as:
> 
>   zero or more of ( model.divWrapper | model.global ), plus
>   one of [main content options for divN], plus
>   zero or more of
>     ( ( model.divWrapper | model.divWrapper.bottom ), model.global* )
> 
> The <note> element is part of model.global. The content model for <div>
> permits a <div> to contain nothing but elements from model.global, but the
> content model for unnumbered divs does not permit this.
> 
> So: is this an error in 0.6, or intentional? If intentional, why the
> difference?
> 
> I sincerely hope it *is* just an error, as we can't be the only folks
> relying on tagging like this:
> 
>     <div1>
>       <div2 type="content">
>         <p>stuff</p>
>         <p>more stuff</p>
>       </div2>
>       <div2 type="notes">
>         <head>Notes</head>
>         <note>note</note>
>       </div2>
>     </div1>
> 
> David
>