There's still input to come from Robert's contacts, but my gut is to ask how could they cascade from map to map? scope=peer means roughly "don't try to reach this resource, it isn't there at the moment". So if the scope=peer is honoured on the mapref, the target map doesn't get touched, and thus values can't be cascaded within it because the target map is never opened.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25
"Ogden, Jeff" <>
"Ogden, Jeff" <>
04/14/2009 11:57 AM
To
Michael Priestley/Toronto/IBM@IBMCA, "Eliot Kimber" <>
cc
"dita" <>, "Robert D Anderson" <>
Subject
RE: [dita] Inheritance of attributes through mapref
So back to the original question, should @scope cascade from map to map or not? Not sure I’m reading Michael’s comments correctly, but I think they are an argument that @scope should NOT cascade from map to map.
-Jeff
From: Michael Priestley [mailto:]
Sent: Tuesday, April 14, 2009 11:52 AM
To: Eliot Kimber
Cc: dita; Ogden, Jeff; Robert D Anderson
Subject: Re: [dita] Inheritance of attributes through mapref
Fair enough. Navref is delayed transclusion, which may or may not be local (one reason to delay transclusion is because the resources aren't local).
It remains logical for someone to want a cross-plugin navigation reference/transclusion that cannot be resolved at build time but will be resolved at runtime (ie format=ditamap scope=peer).
The rationale for scope=peer applies as well to map resources as it does to topic resources.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25
Eliot Kimber <>
Eliot Kimber <>
04/14/2009 11:27 AM
To
Michael Priestley/Toronto/IBM@IBMCA, "Ogden, Jeff" <>
cc
dita <>, Robert D Anderson <>
Subject
Re: [dita] Inheritance of attributes through mapref
On 4/14/09 10:03 AM, "Michael Priestley" <> wrote:
>
> 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.
Hmm. I didn't quite get this from the writeup of navref. It sounded to me
more like delayed resolution rather than a peer relationship, in that the
presentation effect is still that the target map is used in place of the
reference, but the transclusion is done in the renderer, not by the DITA
processor.
I would still take "peer" to imply a navigation relationship, not a
transclusion relationship, the thought being that transclusion essentially
requires local resources (because an unresolveable transclusion can result
in meaningless results) while a broken navigation relationship does not
result in meaningless results (even though the total intended information
set is incomplete).
Cheers,
E.
----
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>
---------------------------------------------------------------------
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
