Re: [dita] referencing a bookmap from a map

[Michael Priestley <mpriestl@ca.ibm.com>]

Hi Eliot,

As a level-set, here's what
the spec currently says about format="ditamap":

http://docs.oasis-open.org/dita/v1.1/OS/langspec/common/theformatattribute.html
The linked-to resource is a
DITA map. It represents a referenced hierarchy at a position within referencing
hierarchy, and a referenced relationship table included outside the referencing
hierarchy 

So it does, at least to me,
read like an explicit behavior. I'd agree that this should be a default
behavior, rather than required. But as a default behavior, I think it should
preserve the validity of the referencing map as it aggregates, and not
create invalid structures.

Earlier you wrote:
>My initial reaction to this
is that it is unnecessarily restrictive because
>map-to-map relationships are not really conref relationships (if you
want
>conref, use conref) but looser composition (of compound map) relationships
>where the relevant constraints and processing implications cannot be
known
>in advance.

Actually if you want conref
you can't use conref - not unless we allow <map> to nest arbitrarily.
Note that the description above says to create the referenced hierarchy
at the current position, but any referenced relationship table should be
included outside. That preserves the validity of the map (which doesn't
allow reltable inside a topicref) in a way that isn't possible with conref.

>That is, when processing a map, a processor need not create a literal
new
>map, but simply process the referenced map as it exists, with knowledge
of
>the referencing context. In that case, the fact that the referenced
topicref
>is a bookmap chapter may or may not be relevant and the user may or
may not
>care.

I agree that when processors
aren't treating the mapref as an aggregator there's no need to generalize.
My concern is for when it is treated like an aggregator, which is at least
the default behavior. 

If someone creates an override
processor, or a specialized element with overriding processing, they can
do what they want. But by default, I think that a topicref to a bookmap
that pulls it into a non-valid context should
generalize (ie treat it like an unspecialized map) rather than create an
aggregate whole that breaks the constraints of the structural specialization.

Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

Eliot Kimber <ekimber@reallysi.com>

06/09/2009 06:20 PM

To	"Ogden, Jeff" <jogden@ptc.com>, dita <dita@lists.oasis-open.org>
cc
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>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php