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] referencing a bookmap from a map


Comments below.

 

   -Jeff

 


From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, June 16, 2009 11:05 AM
To: Ogden, Jeff
Cc: dita
Subject: RE: [dita] referencing a bookmap from a map

 


"Ogden, Jeff" <jogden@ptc.com> wrote on 06/16/2009 10:50:19 AM:

> Yes, that was the example.

>  
> How the TOC and the index look are a styling issues and so the user
> can set this up to be scoped or not.  Processing just sets the stage
> to make that possible.


Just to make sure I understand: your existing indexing process takes a parameter from the user that defines the scope of the index? (the current book, the current map, the highest-level referencing map...).


Or by user setting this up do you mean custom coding?

One of the PTC products is Arbortext/Styler.  Styler allows users to specify how documents are styled, how pages are formatted, and lots of other things.  What is or isn’t included in a TOC or an index, what they look like, and so on are among the things that can be specified using Styler.

 

So it isn’t as simple as “takes a parameter”, but it doesn’t require coding, not even FOSI/FO/XSL coding.

 


What happens by default? In other words, if I have two indexlists in two bookmaps that are pulled together into one map, are the indexlists scoped by default, or not?

 

What happens by default shouldn’t matter to the DITA specification.  The 1.1 specification is entirely silent about these sorts of details. You can sort of guess from the names and some of the element descriptions, but that is all you are doing. I think the 1.2 specification should remain silent on these sorts of details.

 

The key things are that something “reasonable” happen and that it be possible/easy to customize things so something different happens if that is desired.  Where what is “reasonable” is something defined by an implementation or by a user and not something that is mandated by the specification beyond possibly the vaguest statements such as the ones we’ve made for other elements (lists should look like lists, paragraphs like paragraphs, and by extension TOCs like TOCs and indexes like indexes).

 

I think the question we need to answer is what should processing allow?

 

I think I could live with your approach, Michael, if you were to soften it to be something like “processors MAY generalize” rather than “processors MUST generalize”.

 

And I think the problems we are having here are similar to other problems we’ve had with the DITA specification, that we are trying to set things up using our existing syntax when we need a way for users to specify what it is that they want rather than having that implied.  So topicref  format=”ditamap” href="”something.ditamap”" context=”chapter” might do the trick (someone can come up with a better name than context.  Or even lockcontext={ “yes” | “no” } or context={ “override” | “preserve” }.  But these aren’t things that we can resolve for DITA 1.2.

 
Michael Priestley



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