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


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
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
Inactive hide details for Eliot Kimber <ekimber@reallysi.com>Eliot Kimber <ekimber@reallysi.com>


          Eliot Kimber <ekimber@reallysi.com>

          04/14/2009 11:27 AM


To

Michael Priestley/Toronto/IBM@IBMCA, "Ogden, Jeff" <jogden@ptc.com>

cc

dita <dita@lists.oasis-open.org>, Robert D Anderson <robander@us.ibm.com>

Subject

Re: [dita] Inheritance of attributes through mapref

On 4/14/09 10:03 AM, "Michael Priestley" <mpriestl@ca.ibm.com> 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:  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_workgroups.php 


GIF image



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