Original Message-----
> From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> Sent: Tuesday, June 09, 2009 5:07 PM
> To: dita
> Subject: RE: [dita] referencing a bookmap from a map
>
> 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
> >
> >
>
> ---------------------------------------------------------------------
> 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