Lou Burnard wrote,

>  There has been some discussion of what to do about this
> element, since it is a major offendor in the war against attributes,
> having three of the wretched things to dispose of.

I thought this campaign was to be conducted by "surgical" strikes against
attributes guilty of harbouring text, not by nuking every attribute in
sight. It sounds to me as though there's been some "overkill" here. And one
of the three reported casualties may well be a phantom. The P4 content model

<!ELEMENT index %om.RO;  EMPTY>
<!ATTLIST index;
      index CDATA #IMPLIED
      level1 CDATA #REQUIRED
      level2 CDATA #IMPLIED
      level3 CDATA #IMPLIED
      level4 CDATA #IMPLIED>

First off, there's the (confusingly y-clept) attribute named "index", which
is there to "indicate which index (of several) the index entry belongs to. "
I may be missing something, but I can't see what has become of that (to my
mind vital) attribute in the proposed revision. Ascription of an item to one
of several possible indices is a completely different matter from assignment
of a level within one of those indices, and I don't see how it could be
implied by any sort of recursive representation. However, if retained as an
attribute  (and possibly renamed indexno or suchlike if we are really
confident that numbers can/will always be used to discriminate between
multiple indices) then multiple <index> structures belonging to different
indexes could be siblings, with the index/indexno attribute determining into
which index their descendants belong to. So I'd say that the current index
attribute is both necessary and blameless and ought to be kept, under
whatever nomenclature.

I realise that this attribute is indeed retained in the specimen
specification for the index element in the draft; but then so are the other
P4 attributes: the spec for element index is largely a translation of the P4
DTD into the new specification format, and so doesn't tally with essentials
of the discursive redraft . Maybe it wasn't meant to, but then it's somewhat
confusing to have it cheek by jowl with specifications for the proposed new
elements which do contain an abstract notation of the new discursive

Now on my reckoning, once the attribute index has been retained and the
representation of "level" has been reconceptualised, we are left with just
one more attribute slot to be rejigged (i.e. we had essentially only two
attributes in total): the remaining one being that occupied in P4 by the
obligatory level1 and the optional levels2-4. These are plainly Bad
Attributes, because their present specification commits them to having as
their value #PCDATA which is to some degree derived from the base document
text, and therefore liekly to contain chunks of natural language not
expressible in a controlled vocabulary. Here I am conceptually happy enough
with the proposed recursive representation, though I have some pedagogical
doubts (= I don't think I could explain it confidently to a fractious class
on a Friday afternoon without a cheat-sheet too big to be scribbled on the
back of my hand, but that's probably just my advancing years). And anyway,
which of us, however agile of mind, is really capable of explaining
recursion to those congenitally allergic to abstract thought? Although come
to think of it, tackling the markup in P5 of the old chesnut which is of
course allegedly a "real" index entry, namely "Recursion, see Recursion"
might just make things click.

Which, alas, also reminds me of a further issue affecting both P4 and
proposed P5 index markup. If an index is to be <divGen>ed from <index>
elements by an application, what notation, if any, can we use to indicate
that an entry at a given level in a specified index should contain, or even
wholly consist of, a cross reference to another entry in the same or another
index? Do we have to say that in such cases, the index must be hard-coded
rather than <divGen>ned? Or is there some scope for getting tricksy with

One further, much less important, point re the draft (or rather about a
phrase within it retained verbatim from P4). I refer to the formulation
"The <divGen> element marks the place at which an index generated from the
<index> elements should be inserted into the output of a processing
program."  Now that is, of course perfectly true, but the sense in which it
is true (i.e. as one application of <divGen> among many possible others) may
not strike those who don't habitually make the Guidelines their bedtime
reading, and if taken out of context, this phrasing could be taken to say
that this is *all*  <divGen> is used for. So I would suggest rephrasing to
something like "To mark the place at which an index generated from <index>
elements should be inserted into the output of a processing program, the
<divGen> element may be used." Or, less drastically altered but also perhaps
less manifestly indicative of the wider applications, "The <divGen> element
may be employed to mark the place..."

Michael Beddow