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
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Ogden, Jeff" <jogden@ptc.com>
- Date: Mon, 15 Jun 2009 23:34:16 -0400
Hi Jeff,
Was this the earlier example in question?
map
title
topicref to bookmap
topicref to leaningbookmap
It didn't explicitly address TOC and
index behaviors, so I'm going to poke a little more. Is your indexing process
already scoping by containing element (ie if the index is part of the learningbookmap,
then it shouldn't include index entries for bookmap, even if they're part
of the same map)? Or is the indexing process resolved before the topicrefs
are used to combine the hierarchy?
Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Ogden, Jeff"
<jogden@ptc.com>
06/15/2009 10:50 PM
|
To
| Michael Priestley/Toronto/IBM@IBMCA
|
cc
| "dita" <dita@lists.oasis-open.org>
|
Subject
| RE: [dita] referencing a bookmap from
a map |
|
Michael asked:
> Returning to the questions of my previous
notes - if I fed to your processors a normalized
> DITA map that consisted of three concatenated
bookmaps, each with their own indexing and
> TOC behaviors defined, how would your
processors handle them? That's behavior that is
> certainly not defined in the spec, because
it is a content model that is not achievable by
> following the spec.
The simple answer is that it works just fine.
The example I gave in an earlier message was real.
The more complicated answer is that if the
specialized topicref elements are “styled”, then we use them as is. If
they aren’t styled, we generalize back to more basic elements if the base
element is styled and so on until we find a styled element or we run out
of base elements. This is driven by the styled or unstyled nature
of the elements and not based on which element is the referencing and which
is the referenced element. We use this same approach for the specialized
map to specialized map case and for the generic map to specialized map
case. In fact we use this approach for styling all elements from maps or
topics. The key thing is that we start out with the more specialized
elements and only work our way back to the more general elements as necessary.
Of course it doesn’t work if you start with a generalized element to begin
with.
-Jeff
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Monday, June 15, 2009 7:42 PM
To: Ogden, Jeff
Cc: dita
Subject: RE: [dita] referencing a bookmap from a map
Hi Jeff,
For others following the discussion:
http://www.oasis-open.org/committees/download.php/24910/IssueNumber12055.html
>I want the DITA 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.
I don't think it does weaken the argument. We can always define specialized
behaviors for specialized elements. The question is what is the safest
behavior to define as the default for unspecialized elements that have
no other behavior.
>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.
Returning to the questions of my previous notes - if I fed to your processors
a normalized DITA map that consisted of three concatenated bookmaps, each
with their own indexing and TOC behaviors defined, how would your processors
handle them? That's behavior that is certainly not defined in the spec,
because it is a content model that is not achievable by following the spec.
I respect the instinct to preserve semantics rather than discard them.
However, if the preserved semantics can trigger processing rules that will
result in broken output, it seems irresponsible to preserve those semantics
without some kind of indication from the user that specialized behavior
is being engaged. An indication like, for example, the creation of a specialized
referencing element.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]