OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]