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

 

> -----Original Message-----

> From: Robert D Anderson [mailto:robander@us.ibm.com]

> Sent: Tuesday, June 16, 2009 10:51 AM

> To: Michael Priestley

> Cc: dita; Eliot Kimber; Ogden, Jeff

> Subject: Re: [dita] referencing a bookmap from a map

>

> If I may step in to the battle at its most dangerous moment and try to sum

> up what I'm thinking after reading all of this thread at once...

>

> First, my assumptions -

> * I'm going to talk about bookmap because it is easy to use as an example,

> but obviously it's only one case of millions.

> * I have been trying more and more to keep processing out of spec

> discussions. However, I do find it very useful to help understand the

> meaning of how these things are assembled. That said - I'm trying to focus

> on the effective result of map references, rather than on how files might

> be modified by a processor or how the result might be rendered.

>

> With that out of the way - as I understand it, much of Michael's concern

> could be restated as follows: If you are pulling a chapter into another

> map, and you want it to remain a chapter, why are you not pulling it in

> with a <chapter> element? If you are pulling it in with a <topicref>

> instead, doesn't that mean that either a) your current map does not allow

> chapters, or b) you do not want it to be a chapter at this point? So -

> wouldn't the most appropriate result be to try to treat that chapter as

> the referencing element?

 

(a) is the case that I’ve been thinking about. Say you have two maps and one uses “chapter” and one uses “lesion”. You should be able to crate a deliverable that includes both, but without creating a new map specialization for the purpose it is likely that the existing maps will force you to include a chapter as a lesion or a lesion as a chapter.

 

 

> Item 12055 already states that <chapter> may pull in other elements, and

> that it casts them as chapter. It gives a specific example of when this

> may

> produce odd results -- when <chapter> references another bookmap with

> parts. Those parts are cast as <chapter>; if they in turn nest chapters,

> you end up with chapters inside chapters, and 12055 says that the result

> can be warnings, errors, corrective behavior, etc.

>

> With that example in 12055 - we've established a policy where the

> referencing topicref pushes its role onto the target(s). Children of the

> target are not touched, and processors can decide how to handle them when

> the results get wonky.

>

> 12055 also clarifies the fact that new specialized topicref elements *may

> define different behaviors for map references*. This is where it talks

> about the new mapref element, which explicitly does *not* push its role

> onto the targets.

 

I agree that this is the behavior we want for mapref, but how does a processor know that this is the behavior that we want without having to build that behavior into each processor for each new topicref specialization?

 

And why is the behavior for mapref different from a topicref with format=”ditamap” or is it?

 

> Given all of that - I am not sure that we need any new rules for the

> topicref->chapter case. Couldn't it use the same rules?

 

It could, but should it?  Using the same rules is simple, but does it allow us to do the sorts of things that we want to be able to do? I think it prohibits things that we want to do.

 

> I'll try to avoid

> stating this in terms of processing, but somebody else might do a better

> job:

> * By default -- the referencing element pushes its role onto the target.

> <chapter> references to <topicref> become chapters, <topicref> references

> to <chapter> become topicrefs.

> * Children of the target element are not modified

> * If the result does not make sense to you (chapters in chapters, appendix

> in front matter), you are free to do what you want - error, recover, etc

 

This makes it impossible to treat a chapter referenced using a topicref to as a chapter. That isn’t what I want.

 

We need to hear from some others to see what they want or learn that they don’t care one way or another.

 

 

> Now awaiting tomatoes...

>

> Robert D Anderson

> IBM Authoring Tools Development

> Chief Architect, DITA Open Toolkit

>

>

>

>              Michael Priestley

>              <mpriestl@ca.ibm.

>              com>                                                       To

>                                        Eliot Kimber <ekimber@reallysi.com>

>              06/16/2009 10:00                                           cc

>              AM                        dita <dita@lists.oasis-open.org>,

>                                        "Ogden, Jeff" <jogden@ptc.com>

>                                                                    Subject

>                                        Re: [dita] referencing a bookmap

>

 



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