Re: [dita] Issue 33, remove @copy-to: Updated Stage 2 Proposal

[Jim Tivy <jimt@bluestream.com>]

Yes, I was thinking about source to source linkage too without keys.
I was extending the idea of resourceId to the dita source and
extending the idea of anchors to include dita source link targets.
For example, the <resourceid appname="dita" appid="use3"/> could
indicate the resourceId for the source.
Then for the <xref href="oil.xml" resourceid "use3">

Also, use3 is really an instance of the topic whose uri is oil.xml so
resourceid should not be required to be unique across all resources -
just within oil.xml topicrefs.

I also like the idea of a key to reference the "use of" the
"resource". However current text in the Spec talks about a key being a
definition of a URI.  In this resource case, as proposed, the key
indicates a use of the uri in the map - a topicref.  This intent of a
key definition may require some extra specification language.


On Fri, Oct 30, 2020 at 7:44 AM Eliot Kimber <ekimber@contrext.com> wrote:
>
> Jim,
>
> In this example the key is required in order to enable the cross references to specific uses of the topic. Doesn't have anything to do with the anchors.
>
> That is, with resourceid, the keys are only there to enable source-to-source addressing (their primary purpose) and do not contribute (or do not necessarily contribute) to the definition of deliverable anchors.
>
> I think that's one attraction of resourceid for anchor specification--it separates the internal source-level addressing concern (keys) from the deliverable control concern (resourceid).
>
> However, when you *already have* a thorough and consistent use of keys it can make sense to also use those keys to determine deliverable anchors, avoiding the extra work of also specifying resourceids.
>
> So which you prefer depends entirely on your content and workflow and what your processor does for you, but resourceid should always be an option that processors will support.
>
> Cheers,
>
> E.
> --
> Eliot Kimber
> http://contrext.com
>
>
> ïOn 10/29/20, 5:42 PM, "Jim Tivy" <dita@lists.oasis-open.org on behalf of jimt@bluestream.com> wrote:
>
>     Nice proposal.
>     It would be nice to address these different topic renditions in the
>     same map without the use of keys.
>
>     From your example:
>     <topicref href="topic_a.dita" keys="topic_a-use-02" >
>      <topicmeta>
>      <navtitle>Topic A Second Use</navtitle>
>      <resourceid appid="topic.A2"/>
>      </topicmeta>
>      </topicref>
>
>     You have to generate a unique key name as well as a unique resourceid appid.
>     Why not just use the unique appid as the rendition id without the use of a key.
>
>     Perhaps something like this would avoid the requirement of keys:
>     <xref href="../b/oil.xml" resourceid="use3" />
>
>     <topicref href="oil.xml">
>       <topicmeta>
>           <resourceid appid="use2">
>       <topicmeta>
>     <topicref href="oil.xml">
>       <topicmeta>
>           <resourceid appid="use3">
>       <topicmeta>
>
>     In this case the primary identifier is the href ../b/oil.xml but the
>     rendition selector is in the resourceid - "use3 being the appid".
>
>     On Mon, Oct 26, 2020 at 6:58 PM Eliot Kimber <ekimber@contrext.com> wrote:
>     >
>     > I have updated the stage 2 proposal for Issue 33 to reflect the reviewer's comments.
>     >
>     > Cheers,
>     >
>     > E.
>     >
>     > --
>     > Eliot Kimber
>     > http://contrext.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
>
>     ---------------------------------------------------------------------
>     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
>
>
>
>