Thanks for the quick feedback Michael: in particular (and even though
you haven't answered the questions I asked) for having drawn to my
attention an utterly confusing mistake in my hasty generation of the
HTML draft -- it picked up the old P4 definition for the <index> element
instead of the new one. I will try to sort that out and post an improved
version tomorrow.

Three brief remarks in response to your other comments:

1.  The attribute formerly known as "index" is indeed not to be removed:
it has been named "indexName", as an example at the end of the draft
shows, and some discussion provided about how you might use it.

2.  I can't see any obvious way of using <index> to generate cross
references *within* a generated index; it is not really meant for that
purpose. The location/s which appear under the index term are to be
auto-generated from the location of the <index> element, so  I suppose
you could do something like
if you really wanted to upset your fractious Friday afternoon class

3. Your comments on the wording re. <divGen> are well taken, and I will
have another hack at the prose accordingly.

The sortKey attribute is a nice new feature, I hope you agree.


Michael Beddow wrote:

>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