[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Groups - DITA 1.1 Issue #45: Add See, See Also indexing elements (IssueNumber45.html) uploaded
> -----Original Message----- > From: Chris Wong [mailto:cwong@idiominc.com] > Sent: Wednesday, 2005 September 28 11:15 > To: dita@lists.oasis-open.org > Subject: RE: [dita] Groups - DITA 1.1 Issue #45: Add See, See > Also indexing elements (IssueNumber45.html) uploaded > > I'm kind of surprised to see no questions or objections so > far to this proposal. I hear that people can have strong > opinions about this subject. I'd like to see any debate get > underway so we will have time to move this issue forward. Anyone? > > Download Document: > http://www.oasis-open.org/apps/org/workgroup/dita/download.php/14639/Iss ueNumber45.html There is something about indexterm (irrespective of this current proposal) that has always concerned me: its mixed content model. Is something like: <indexterm>Top level <indexterm>Nested</indexterm> index term content. </indexterm> allowed (the DTD allows it)? If so, what are the processing expectations? Also, what are the processing expectations of <indexterm>Top level <indexterm>Nested 1</indexterm> <indexterm>Nested 2</indexterm> </indexterm> (the DTD allows this too)? More on this particular proposal -------------------------------- What is the suggested content model now for indexterm? Indexterm already had a mixed content model, but now it seems even "more mixed" (if such is possible). Can one have #PCDATA following <index-sort-as>...</index-sort-as>? If there is going to be an index-sort-as, will it always be the first child element of the indexterm element? Is one limited to at most one index-see or index-see-also? If one has an index-see, can one have an index-see-also? Is the semantic that if one has an index-see, one doesn't show the page number on the parent indexterm, but otherwise one does? We currently have the following content model: <!ELEMENT indexterm (%words.cnt;|%indexterm;)* > I'm guessing we might want a content model something like: <!ELEMENT indexterm ((%words.cnt;)?, (index-see | index-see-also+)? , indexterm?) > except you can't do that in XML, so we're probably going to have to allow just a big mash of text and tags, and write "application semantics" that say it's only dita-valid if it matches the above non-XML content model. Regardless, the proposal needs to describe what is valid input and how to handle all possible input. The entire discussion of "linking to other indexterms" confuses me. I don't see any linking to indexterms. There are just indexterms scattered throughout the content, and when the index is automatically generated, entries therein pick up the appropriate page numbers and possibly link to the point in the result where the indexterm element was found, but there are no links to the indexterms. Perhaps it's just the wording that confuses me, but it makes no sense to me to say, for example: ...the reference to "Goldfish feeding" points to a nested indexterm. We need to define an identifier that a redirection element such as index-see can use to point to something yet to be generated. Page ranges make me nervous. They are difficult to implement correctly, and they are easy to use incorrectly. Especially given that <index-range-start/> and <index-range-end/> are unpaired singleton tags, it's easy for a user to use them in ways that aren't going to be valid. I'm not sure what user requirement is being addressed by ranges. Is it just to be able to get something like 46-49 in the index, or is it to allow a user to just indicate a startpoint and endpoint in the source without having to insert individual indexterm elements on each page? The former is just an implementation issue and shouldn't drive our markup, but I can see the point of the latter. But we do have to ask, then, if the benefit of this is enough to offset the problems. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]