RE: [dita] referencing a bookmap from a map

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

I withdraw my objection, which was semantic in nature.

There have long been two philosophies of software design as regards
responsibility. One is the UNIX approach, where you can do pretty much
anything and shooting oneself in the foot is not prevented, perhaps
being considered a learning experience. The other, in contrast to this
anarchic situation, is the old PDP-11 or Nazi approach where the the
Thou Shalts and the Thou shalt nots are spelled out and enforced. The
unruly and the ruly.

DTD and schema are inherently ruly, but map/topicref is generic, not
restricted as to what kinds of things can be aggregated in a single map.
As we saw in the discussion of aggregated editing, map/topicref escapes
validation constraints (the targets can only be presumed each severally
to have been validated). As matters currently stand, foot-shooting is
not prohibited, and the consequences thereof are pretty much left up to
the inventiveness (or not) of the implementor.

If we leave it this way, it would be kind of us to identify combinations
of topicref targets that should be avoided, such as those that have the
effect of allowing chapters to nest, and point them out in the spec. 

	/Bruce

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Tuesday, June 09, 2009 12:25 PM
> To: Michael Priestley; Ogden, Jeff
> Cc: dita
> Subject: Re: [dita] referencing a bookmap from a map
> 
> On 6/9/09 11:06 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:
> 
> > Hi Jeff,
> > 
> >>   Topicref to bookmap:
> >>      Chapters in the bookmap maintain their ?chapterness?
> >>      Parts in the bookmap maintain their ?partness?
> > 
> > If we think of a mapref as being parallel to a conref (basically a 
> > shorthand for "pull the target hierarchy into this point in this 
> > hierarchy, but push reltables to the end because they're 
> not allowed 
> > within a hierarchy") then we should discard the chapterness - just 
> > like we discard <step>ness when we conref from a <li>.
> > 
> > Otherwise we allow chapters to nest, and break any bookmap 
> processors 
> > that are expecting DTD-validated content.
> 
> 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.
> 
> 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 think part of this discussion may result from an inherent 
> bit of fuzziness in the design of map-to-map references, 
> which is that there is no necessary well-defined thing that 
> is the target of the reference to which, for example, a type 
> check could be applied.
> 
> That is, there is no requirement that a referenced map have 
> exactly one root topicref. In the case where there is no 
> single root topicref, there is nothing to which a topicref 
> could be unambiguously checked except the map element itself, 
> but the map element is not reliably distinguishing (consider 
> the L&T map domain, which allows the inclusion of very 
> specialized topicrefs into an otherwise unspecialized <map> element).
> 
> So I think we are obligated to say that map-to-map references 
> are unconstrained by the spec and its up to processors to 
> decide what is or isn't meaningful for a give use instance.
> 
> Certainly in my "library map" use case, where I want a map 
> that points to multiple bookmaps, my intent is clear and I 
> can implement processing that makes it sensible, and that 
> processing will almost certainly not be to treat the entire 
> map as a single virtual map instance document but to treat 
> the library map as a set of navigations to the otherwise 
> individual bookmaps.
> There's nothing in the current DITA language that lets me 
> express this intent directly (unless it's possibly 
> scope="peer" on a map-to-map reference, but scope="peer" is 
> seriously underspecified in the 1.2 spec as currently drafted 
> and certainly doesn't address this particular question).
> 
> I would be very uncomfortable saying that processors are 
> *obligated* to treat references to specialized topicrefs as 
> generalized. I would be OK with saying they *can* treat them 
> as generalized.
> 
> I would also be OK with saying that the type= attribute can 
> indicate the type of the top-level topicrefs a given 
> map-to-map reference effectively addresses, e.g.:
> 
> <topicref href="mybookchaptermap.ditamap" type="chapter"/>
> 
> If this form of type= was required in order to preserve the 
> specialized nature in processing referenced topicrefs, I 
> would be OK with that, since it doesn't preclude the 
> functionality but does make intent clearer and enables 
> designers to build in constraints in specializations.
> 
> 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_workgr
> oups.php 
> 
>