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] indexing question


As I said, the issue of moving content out of the narrative flow is a
wider problem than just indexing. There are a lot of elements that can
be moved out of the narrative flow, and they in turn have processing
implications for all kinds of stuff like keywords, footnotes,
indentation and conditional processing. The index range is just one part
of it. I would argue that moving content around like this is nonstandard
behavior, and if you want to do that you're on your own. Not that this
rearranging is a bad thing, but it's hard to encompass in a
specification all possibilities that creative minds can cook up in the
realm of processing.

On range locations, you brought up the case of a range starting in a map
and ending in a topic. This is already illegal in the current proposal,
so I don't see where the issue lies. If all you want is explicit
language that index ranges that start in the map ends in a map then I'm
fine with that.

Chris 


-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com] 
Sent: Tuesday, July 25, 2006 8:44 AM
To: dita@lists.oasis-open.org
Subject: RE: [dita] indexing question

 

> -----Original Message-----
> From: Chris Wong [mailto:cwong@idiominc.com]
> Sent: Tuesday, 2006 July 25 08:30
> To: Grosso, Paul; dita@lists.oasis-open.org
> Subject: RE: [dita] indexing question
> 
> When you move images like that -- effectively converting them into end

> notes -- you are  moving content out of the narrative flow.

Agreed.

> This is not
> so much an indexing problem as it is a general DITA issue. 

Agreed.  Formatting is a hard problem, and writing specs for such is
difficult too.  That doesn't mean we can punt.

> We cannot
> and should not decide every possible processing variant.
> 

I think you have to.  You cannot write a standard that doesn't address
some situations.  You can address them by saying that we leave it up to
the implementation to decide what to do (though that should be done only
when necessary), but you cannot write a standard that says "do index
ranges--you know what I mean".

So, what is the answer to my question?  I think the DITA spec has to
answer it.  I'd be happy to say that the image is not part of the index
range, but we have to put something into the spec about this.

> As for the Q 6 and 7 response below, we already have a prescribed 
> behavior for orphaned or misarranged index range pairs. It applies to 
> both maps and topics. I still don't see what the issue is.
> 

You are correct that we already have prescribed behavior, and we could
stick with that as an unambiguous solution.

I am pointing out some drawbacks from the user's point of view to your
suggested solution.  I am asking the TC to consider if the supposed
benefits of being able to start an index range in a map file and end it
in a referenced topic [What are the use cases?  Is there ever any good
reason to do this?  Doesn't this make reuse of topics impossible if a
topic ends an index range that is expected to be started in a map?] are
outweighed by the disadvantage of not being able to flag this as an
error.

I prefer to say that having an index range that starts in a map file has
to end in the map file or else it's an error.
I think that is preferable behavior.

paul


> Chris
> 
> -----Original Message-----
> From: Grosso, Paul [mailto:pgrosso@ptc.com]
> Sent: Friday, July 21, 2006 11:09 AM
> To: dita@lists.oasis-open.org
> Subject: RE: [dita] indexing question
> 
>  
> 
> > -----Original Message-----
> > From: Chris Wong [mailto:cwong@idiominc.com]
> > Sent: Tuesday, 2006 July 18 09:19
> > To: Grosso, Paul; dita@lists.oasis-open.org
> > Subject: RE: [dita] indexing question
> 
> > 
> > 5 and 6: an index range is just a range: any content
> between two index
> 
> > range markers constitute the index range. An index range
> starts where
> > it starts and ends where it ends. That includes figures,
> part or whole
> 
> > paragraphs ... anything. That is the point of the index
> range marker,
> > that it can express index ranges in a manner orthogonal of the XML 
> > structure. I don't see the ambiguity: why should anything
> NOT be in an
> 
> > index range if so delineated?
> 
> Suppose I have something like (pseudocode, not actual tagging used):
> 
>   start index range
>   para1
>   image
>   para2
>   end index range
> 
> Now suppose, because my stylesheet says all images get floated to the 
> end of the topic they are in, para1 starts on page 15, para2 ends on 
> page 16, and the image floats to page 22.
> 
> What index entry should be generated?  One with 15-16 for the page?
> Or one with 15-16,22 for the page?
> 
> I see the ambiguity.
> 
> > 
> > 7: I'd answer "yes": that seems the obvious interpretation. 
> An index
> > range starts where it starts, and ends where it ends.
> 
> On questions 6 and 7, the issue here really is whether we want to 
> allow index ranges that are completely asynchronous to both the markup

> structure and even the file structure.  It can be both a processing 
> problem as well as a debugging nightmare (for the user) if we allow 
> such asynchronicity.
> Imagine a user mistakening switching index-range-start and 
> index-range-end (so the end comes before the start) in a topic and 
> then having an index range surrounding that topic in the map file.  If

> we allow the "end"
> within the topic to end to "start" in the map file, there will be no 
> errors, but the result is not going to be what the user wanted.
> 
> So one other obvious interpretation is that it is an error for an 
> "end"
> not in the map file to end a "start" in the map file.
> 
> paul


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]