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


On 6/9/09 5:00 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:

> There are two classes of users here. Authors and implementers.
> 
>  
> 
> Different authors will feel differently about being allowed or
> prohibited from shooting themselves in the foot.  And they may feel
> differently still before and after shooting themselves in the foot.
> 
>  
> 
> Implementers (like me) are looking for some guidance. Should we keep
> authors from shooting themselves in the foot, warn them, but let them
> shoot themselves in the foot if they wish, or just let them shoot
> themselves in the foot without any warning. And if we let them shoot
> themselves in the foot, should different implementations always shoot
> the same foot or can some implementations shoot the left foot while
> others shoot the right, while still others shoot the head? As an
> implementer, what I want to avoid is having someone say that after we
> shot them in the right foot that we should have shot them in the left
> foot because that is what some other implementation does or what the
> DITA specification calls for.
> 
>  
> 
> To get back to DITA maps, it would seem that we have some choices, but
> I'm losing track of who is pushing for what:
> 
>  
> 
> 1)       Make map to bookmap illegal, Bruce's original approach, now
> withdrawn.
> 
> 2)       Allow map to bookmap, where the bookmap context is not
> overridden by the map, my proposal from earlier today, still on the
> table.
> 
> 3)       Michael's proposal that I'm not sure I understand, but which
> would have map references behave more like conref and so presumably more
> specialized topicrefs would be generalized to less specialized
> topicrefs, or pretty much the opposite of approach #2 (Michael, correct
> me if I got your proposal wrong).
> 
> 4)       Eliot's proposal, which I'm not sure I understand, but which
> seems to be "anything goes" leaving it up to the implementers (Eliot,
> correct me if I got your proposal wrong). .  Eliot would proposal #2
> allow you to do what you want to do?

I'm saying #2, without bothering to say anything about "bookmap context"
because that's a processor-specific implementation detail. Either processors
are *obligated* to treat more-specialized topicrefs as generalized to the
level of the referencing topicref (Michael's proposal) or they aren't. If
they aren't, then how they remember what the unspecialized type of a given
topicref is is an implementation detail.

I'm also suggesting that any implementor, e.g., Arbortext, is free to say,
for that implementation, whether a particular case is or isn't meaningful,
so if Editor said "maprefs from <map> to <bookmap> aren't sensical *to us*"
I would be fine with that. But if it instead "this is the sense it does make
to us" I would be fine with that too (from a conformance standpoint).

Cheers,

E. 

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com> 



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