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] Review #2 comment: Links between maps

This is the "cross-deliverable addressing" proposal.

The intent of the proposal is that maps referenced with a scope of "peer"
where the referencing topicref also defines a key scope enable the
referencing of keys in the target peer map without making the target map's
entire key space part of the referencing map's key space.

In particular, it is not necessary for the processor operating on the
referencing map to be able to actually get the peer map and construct it's
key spaces: because the target map has a scope of "peer" processors
thereby know that they can defer resolution of the key reference (that is,
cross references to the key, no other form of key reference would make any
sense) to a later phase of processing *if* the target map is not available
at the time the input map is initially processed.

However, the DITA spec has always said (or implied) that one implication
of "peer" is that peer resources are typically managed together, as
distinct from "external", which is, by definition, separate from the local
resource set.

The intent of the language quoted is to clarify that "peer" means "you
don't have to process the target immediately but you might be able to
because peer usually implies availability of the peer resource".

So the challenge is how to say that in a way that makes sense and doesn't
imply or impose any particular processing implementation.

I'm not sure I ever considered the implication of processing-role of
"resource-only" for cross-deliverable linking, but I think that using a
value of resource-only would be non-sensical since the implication of
"resource-only" is that the thing is not part of your "navigation set".
The whole purpose of creating a cross-deliverable map reference is to
enable navigation to that map, so I think the value either has to be set
to "normal" or peer maps referenced via resource-only topicrefs should be
ignored or the value "resource-only" should be ignored since the only
meaningful value can be "normal".


Eliot Kimber, Owner
Contrext, LLC

On 11/4/14, 9:47 AM, "Kristen James Eberlein"
<kris@eberleinconsulting.com> wrote:

>    Referring another comment to the TC for discussion:
>    Topic = Links between maps
>    DITAweb URL: 
>      between maps
>    Prose in question:
>    "When a key scope is defined on a topic reference to a DITA map and
>    the value of @scope is "peer", then the referenced map is a peer map
>    with respect to the map making the reference. The implication of a
>    scope of "peer" in this case is that the target map is managed along
>    with the referencing map such that the author or processor of the
>    first map likely has access to the referenced map as well."
>    Comments:
>* David Helfinstine: "What is the difference between
>        scope="local" and processing-role="resource-only" and
>        scope="peer" and processing-role="resource-only". Redefining
>        "peer" to now say you may open this at build time because the
>        content "may" be available at build time seems confusing.."
>* Robert Anderson: "Discussion with Kris - I don't think we can
>        answer this on our own. Referring to TC for discussion.."
>    -- 
>      Best,
>      Kris
>      Kristen James Eberlein
>      Chair, OASIS DITA Technical Committee
>      Principal consultant, Eberlein Consulting
>      www.eberleinconsulting.com <http://www.eberleinconsulting.com>
>      +1 919 682-2290; kriseberlein (skype)
>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:

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