> Can someone please explain why the restrictions on the nesting of
> the <note> element is deemed a short-coming and calls out for an
> extension when <div type="note> is available?
Is Perry's "notes preceding chapter headings at the top of divs"
insufficient evidence? Certainly you can imagine a footnote anchored
to the end of a chapter title, but before the subtitle; or (because
many would consider the footnote to be best encoded inside the first
<head>), scribbled in between the two (an <add> is not allowed
between two <head>s at the top of a <div>, either; and bracketting
the <note> with <addSpan>s does not make the following <head> valid).
Or a note in the midst of poetry. Certainly the argument "I don't
want to encode the <note> inside the <l>, as it is not part of the
metrical line (and I don't want to count its syllables as feet or
have it mess up my rhyming algorithms)" is reasonable, no?
While I'm not claiming that there are no ways to encode these with
the current Guidelines, I am saying that
a) <div type="note"> won't work, and makes no sense, and
b) the encoding that many folks would find most natural, i.e.
<div type="invalid_example"> <lg type="invalid_example>
<head>Main Title</head> <l>Metrical line 1</l>
<head type="sub">Subtitle</head> <l>Metrical line 2</l>
is not available.
> I ask because I am not clear, without a use case at hand, that
> all the richness of the object-of-study will be flattened by an
> encoding that makes all segments-to-be-tagged that look like
> notes equivalent.
I'm not at all confident I understand what you're saying here. But I
will point out that if encoding all things that look like notes as
<note> causes more flattening than you desire, stratifying them with
the type= attribute should do the trick.