[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Issue 33, remove @copy-to: Updated Stage 2 Proposal
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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]