My apologies for seeding confusion. I did not intend for folks to
consider <div type=note> and <note> to be synonymous when I asked:
> 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?
My intent was to invite reflection on the possibility of reading from
placement a difference of kind (and encoding that difference at the
level of the element and try to do so at the level of attributes
<note type="extension"> as suggested by Syd).
Lou suggests the use of <ptr> to do some linking.
Would the use of the "corresp" be an alternative and appropriate way
linking <note> elements in some of the cases identified by Syd Bauman?
<l id="verse12" ana="note55" >this little line of verse<anchor
<note id="note34" corresp="anote34"> a note anchored to a spot....
<note id="note55" corresp="verse12"> a note connected to an element...
Any one have any experience processing documents marked up this way?
Compared to those using <ptr>?
> From [log in to unmask] Wed Apr 2 17:43 EST 2003
> Approved-By: [log in to unmask]
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> Message-ID: <[log in to unmask]>
> Date: Wed, 2 Apr 2003 21:55:05 +0100
> Reply-To: Burnard Towers <[log in to unmask]>
> Sender: "TEI (Text Encoding Initiative) public discussion list"
> <[log in to unmask]>
> From: Burnard Towers <[log in to unmask]>
> Subject: Re: note and type attribute
> To: [log in to unmask]
> In-Reply-To: <[log in to unmask]>
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Length: 2427
> I offer some justification below for things-as-they-currently are with
> respect to these oft raised issues.
> 1. The discussion about <note> seems to confuse the physical placement of
> the note in the running (print) text with its ontological status as an
> annotation. Not surprisingly, since of course the <note> element as it is
> usually used conveys both at once. When we encode a <note> inline, we like
> to place it (as the Guidelines say) "at its point of attachment", and thus
> convey both the point of attachment (the place in the text which is being
> annotated) and the annotation itself economically with one element. This is
> usually fine in running text, but there are places where it is difficult or
> inconvenient to do so, such as the examples variously cited by Perry and
> The solution, for those who don't want to clutter up the m.Incl class, is to
> use two tags. Use a <ptr> with an appropriate value for its TYPE attribute
> to mark the point of attachment, and put the <note> somewhere else, probably
> with all the other <note>s in a special purpose <div>. Yes, this makes the
> processing a bit more complicated -- but then processing notes properly is
> *already* complicated anyway.
> 2. The TYPE attribute should not be global, as its use needs to be carefully
> controlled. It has no specific semantics: a <foo type="bar"> is any kind of
> subclass of <foo>. This has several implications. Firstly care should be
> taken not to use it simply to mean "it's like a foo but really it's a bar".
> (This is why suggesting that<note> is synomyous with <div type="note"> is
> just plain wrong, as Syd points out). Secondly, some elements cannot and
> should not take the TYPE attribute for the good reason that we already have
> ways of subclassifying them by using distinct element names. Thirdly, some
> elements have specifically-named attributes tied to a particular kind of
> subclassification: for example, <title> has a LEVEL attribute which is used
> to distinguish analytic, monographic, serials etc. If TYPE were allowed on
> <title> you can be sure that someone would use it instead of LEVEL to do the
> same thing.
> In general, TYPE is best used only on elements which are entirely generic
> (such as <div>, <seg> etc.) .
> I would be interested to see some specific cases where people have found it
> necessary to introduce it before I readily agreed that it should be made
> global. It's a very sharp weapon, and not a panacea!