RE: [dita] Inheritance of attributes through mapref

From
Ogden, Jeff <>
Date
2009-04-14T14:49:48+00:00
ID
Thread
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

1.   
errors for which an implementation SHOULD report an
error or warning message and MAY, but is NOT REQUIRED to, recover by assuming a
value of "local" and continuing; or 

2.   
that results are implantation specific and as a
result values of @scope other than "local" SHOULD be used with
caution since they may not produce the same results when used with different
implementations.

 

   -Jeff

 

> -----Original Message-----

> From: Eliot Kimber [mailto:]

> 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"
<> 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:  
<mailto:>

> 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>