Comments below.
-Jeff
From: Michael
Priestley [mailto:]
Sent: Tuesday, June 16, 2009 11:05
AM
To: Ogden, Jeff
Cc: dita
Subject: RE: [dita] referencing a
bookmap from a map
"Ogden,
Jeff" <> 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
