[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] referencing a bookmap from a map
|
Earlier Michael wrote:
> So with respect to
I wrote the paragraph quoted by Michael above, but I’m guessing that his questions are more directed to Eliot.
I want the DTIA TC to make our expectations explicit when a generic map references a specialized map (or a generic topicref references a specialized topicref). I hope we don’t end up just saying that this behavior is undefined or implementation dependent, but even that would be better than just being silent or ambiguous about what the expectation is.
I am happy with the behaviors prescribed in 12055.
I don’t think that the behaviors prescribed in 12055 always give results that conform to the expectations of the referencing map’s DTD or schema. And that is fine with me. But in my view this weakens the arguments that say that we should always generalize the top level elements in the generic to specialized case to ensure that they conform.
So, I am not in agreement with either Eliot’s or Michael’s arguments (proposals #3 and #4) and continue to think that proposal #2 (included again at the end of this note) is a good approach.
Proposal #2 does set some expectations and makes it at least possible for users to expect similar results from one implementation to another. Proposal #2 maintains the more detailed information from the specialized maps and so would allow for, but not require, generalization by a processor that wanted or needed to do that. It is certainly the case that unexpected combinations might not produce exactly the results the user is looking for, but they should produce some results and I would hope that it would be fairly easy for users to customize existing processors to do what they want in such situations. I think proposal 12055 already sets the stage for this in the specialized to specialized map case and so extending this to the generic to specialized map case is a fairly natural solution. It is certainly pretty easy to explain (specialized trumps generic).
It is possible that my thinking on this is too much influenced by the implementation we have here at PTC/Arbortext. Or perhaps the PTC/Arbortext approach is a good one and can help us figure out what we want to do here. Let me describe it and you can decide for yourselves:
The PTC/Arbortext DITA support is divided into three parts:
With this approach we’ve divided processing into two parts, “processing” and “styling”. This division is admittedly somewhat arbitrary, but useful never-the-less.
Processing sets the stage for styling by implementing the requirements of the DITA specification and otherwise organizing information so that styling can be easily applied.
Styling is mostly about what the output looks like. It includes those things that the DITA specification does not and should not mandate such as font family, type, size, color, paper or output size, number of columns, …. Users should be able to easily customize the default styling to achieve the results they desire. Exactly how users do this will vary from implementation to implementation.
Users have a great deal of control over “styling” and little or no control over “processing” (or at least not much control unless they are willing to enter into the world of programming).
And my thinking on the question of references from generic to specialized maps has us maintaining as much information as we can as part of the “processing” steps so that that information is available during the “styling” steps. This allows users to make their own choices about what it is they do or don’t expect and how they want to “style” any unexpected cases.
-Jeff
From: Michael
Priestley [mailto:mpriestl@ca.ibm.com]
The following is what I labeled proposal #2: From: Ogden, Jeff
[mailto:jogden@ptc.com]
One approach to this is to simply say that the context (“chapterness”, “partness”, or …) does not cascade when a generic topic reference is used. Where a generic topic reference is a reference from a topicref or any topicref specialization defined in mapgropup-d (mostly this just picks up mapref).
The idea is that we don't want to lose the more detailed context that is available from a topicref specialization when maps or branches of maps are referenced using generic topicrefs that contain less information.
This might or might not also be combined with a note that says that such references are discouraged and that implementations MAY, but are NOT REQUIRED to, issue warning messages in such cases.
So,
Topicref to bookmap: Chapters in the bookmap maintain their “chapterness” Parts in the bookmap maintain their “partness”
Chapter to map: Top level topicrefs in the map receive “chapterness”
Part to map Top level topicrefs in the map receive “partness”
-Jeff
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]