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] Inheritance of attributes through mapref

I'd go for 2) since in fact format=ditamap and scope=peer is basically a navref element. It definitely shouldn't be an error.

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
Inactive hide details for "Ogden, Jeff" <jogden@ptc.com>"Ogden, Jeff" <jogden@ptc.com>

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

          04/14/2009 10:49 AM


"Eliot Kimber" <ekimber@reallysi.com>, "Robert D Anderson" <robander@us.ibm.com>


"dita" <dita@lists.oasis-open.org>


RE: [dita] Inheritance of attributes through mapref

We don't need to provide a meaning for all possible combinations of all attribute values. And I will argue that it is better/simpler/more understandable if we don't.

So, for something like @scope we could say that when @format="ditamap" that the only meaningful value for @scope is "local", that in this case other @scope values are either


> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Tuesday, April 14, 2009 9:59 AM
> To: Robert D Anderson; Ogden, Jeff
> Cc: dita
> Subject: Re: [dita] Inheritance of attributes through mapref
> On 4/14/09 8:43 AM, "Robert D Anderson" <robander@us.ibm.com> wrote:
> > 2) What about the scope attribute? This is intended to describe the
> scope
> > of the target of the topicref. In the case of a normal topic reference,
> > scope="peer" means the target is not part of the current set of
> > information, and may not be available, but is part of my overall
> > information set (I think of this as a reference from one Eclipse plug-in
> to
> > another). However, if I set @scope="peer" on a reference to a map - does
> > that scope attribute describe the map (may not be available, part of
> > another information set), or does the scope attribute cascade to the map,
> > essentially resulting in a local map with full of peer topics?
> >
> > In the off-list discussion, Jeff Ogden has been pushing for the first
> > behavior (@scope=peer means the map is outside of the current
> information
> > set). I now have an action to go back to my users in IBM who are
> depending
> > upon the second behavior, so we can see what impact this will have
> and/or
> > see if they have other good reasons to keep this behavior.
> What would the processing implications be for a reference to a map that is
> not scope="local"?
> At the moment, the only well-defined meaning for a topicref to a map is
> inclusion of the map's elements in the set of effective elements of the
> resulting compound map. There is no notion of a navigational relationship
> that I know of in the current spec, which is the only thing I can imagine
> scope="peer" or scope="external" to mean (if it does not simply imply
> value
> propogation).
> The other possible behavior, that the @scope would propagate to the
> referenced map seems reasonable in that from the standpoint of the
> referenced map as authored, the topics it points to may be local but in
> the
> context of the referencing map they are peer or external, which would have
> the effect of changing the nature of how the compound map is rendered
> (depending on the details of how the processor using the map treats scope
> differences). Establishing this behavior would not require changing
> anything
> about what the spec says in this case, since we would not be changing the
> meaning of scope != local for topicrefs, whatever it means.
> If we accept Jeff's preference, then I think we would be obligated to say
> explicitly what it means to point to a non-local map, and I would think it
> establishes the non-local map as a root map to which a navigation
> relationship is established (that is, treating the target map as the root
> of
> a separate unit of publication, rather than a component of a compound map).
> At the moment, the only spec-defined behavior for topicref references to
> maps is virtual inclusion on the map element's children.
> [NOTE: I think the DITA spec actually needs a way to explicitly create
> map-to-map navigation relationships of the peer and external forms, but I
> don't think we can reasonably do it in 1.2, any more than we can other
> linking semantics recently discussed.]
> Cheers,
> Eliot
> ----
> 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>

GIF image

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