Earlier Michael wrote:
> So with respect to
>
> Proposal 12055 is clear about what we do in the specialized map to
> >
generic map case and also about the specialized map to specialized
> > map
case, but we're not sure what should happen when a generic map
> >
references a specialized map.
> You are saying that we shouldn't say? What about the rest of the behaviors
prescribed in 12055?
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:
The syntax called for and
enforced by the DITA DTDs and XML schemas.
The processing semantics called
for or allowed for by the DITA specification.
The styling that is applied to
the processed result to yield the final composed output.
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:]
Sent: Friday, June 12, 2009 5:32
PM
To: Eliot Kimber
Cc: dita; Ogden, Jeff
Subject: Re: [dita] referencing a
bookmap from a map
So with respect to
>
> Proposal 12055 is clear about what we do in the specialized map to
> >
generic map case and also about the specialized map to specialized
> > map
case, but we're not sure what should happen when a generic map
> >
references a specialized map.
You are saying that we shouldn't say? What about the rest of the behaviors
prescribed in 12055?
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25
The following is what I labeled proposal #2:
From: Ogden, Jeff
[mailto:]
Sent: Tuesday, June 09, 2009 10:34
AM
To: dita
Subject: RE: [dita] referencing a
bookmap from a map
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
