[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] RE: [Dita-ot-developer] Handling of xref attributes
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Thursday, February 09, 2006 4:14 PM
To: Paul Prescod
Cc: dita@lists.oasis-open.org; dita-ot-developer@lists.sourceforge.net; Robert D Anderson; Su-Laine Yeo
Subject: Re: [dita] RE: [Dita-ot-developer] Handling of xref attributes
Re the scope attribute: the current definition is this:
The scope attribute identifies the closeness of the relationship between the current document and the target resource.
- Set scope to local when the resource is part of the current set of content, and should be accessed and copied to the output directory.
- Set scope to peer when the resource is part of the current set of content but is not accessible at build time.
- Set scope to external when the resource is not part of the current information set and should open in a new browser window.
Re:
>Having components authored by other people is the norm in topic oriented
>authoring. If it is part of your "information set" then the momentary
>unavailability of the information strikes me as a transient problem that
>should be reported as a warning. If I shut up the warning by setting the
>scope attribute to "peer" then I'll never fix my problem before
>publishing.
If it's a transient problem you wouldn't set scope="peer" you'd set scope="local". But if it's an ongoing situation (like, for example, you are publishing a component of a website, and someone else from another company is publishing another component) then while you are part of different publishing streams you are converging on the same deliverable, and want the output to act integrated even though some of the info has to be "faked" at build time. That's when you set scope="peer".
I hope that clarifies.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]