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

[Eliot Kimber <ekimber@contrext.com>]

I'm not sure what you mean by "However current text in the Spec talks about a key being a
    definition of a URI."

A key provides a unique name for *a topicref*. A topicref represents a resource, which may be one of three possible things:

1. A DITA topic or map (a "DITA resource")
2. A non-DITA thing (an image, an external Web site, etc.)
3. Text with no associated URI-addressed resource

The first two things are addressed by URI, so for those things, a key is effectively an name bound to a URI, but it's really a name bound to the *resource* addressed by that URI.

The third thing is just a resource with no URI

Cheers,

E.

--
Eliot Kimber
http://contrext.com
 

ïOn 11/2/20, 8:54 PM, "Jim Tivy" <jimt@bluestream.com> wrote:

    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
    >
    >
    >
    >