RE: [dita] conref.dita editorial review

["Ogden, Jeff" <jogden@ptc.com>]

Is this description specific to conkeyref or is it a more general
description of key references?

In the more general key reference case, a key definition may include
@href, title, and metadata resources. Which resources are used depends
on which resources are applicable in the context in which the key
definition is being used and it is possible to use more than one
resource to resolve a key reference.

I had assumed that only the @href resource would be used to resolve a
@conkeyref and that title or metadata resources would be ignored. Is my
assumption incorrect?

   -Jeff

> -----Original Message-----
> From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> Sent: Wednesday, November 25, 2009 12:12 AM
> To: Eliot Kimber; Michael Priestley
> Cc: dita
> Subject: RE: [dita] conref.dita editorial review
> 
> [Just got SVN working again. Thanks, Kris.]
> 
> I think the following revision resolves question 2. Please let me know
> if problems remain.
> 
>     A key is bound to the resource addressed by the <topicref>
>     or <keydef> in which it is defined. The resource to which
>     a key is bound may be a DITA map or topic, or it may be a
>     non-DITA resource such as a graphic or an object specified
>     by an external URI. If no address is provided, the key is
>     bound to the information provided by the <topicref>, such
>     as a title and metadata.
> 
>     When a key is bound to an element within the <topicmeta>
>     of the key-defining <keydef> or <topicref>, the content of
>     that element is rendered as the content of the referenced
>     element. By this means, the referenced element can be used
>     as a variable, and the content of the bound element in
>     the definition in the map provides a way to set the
>     variable's value wherever that key occurs within the
>     document aggregated by that map.
> 
> Eliot: can a key be bound both to an element in the local <topicmeta>
> and to the resource referenced by the @href attribute in <topicref> or
> <keydef>, at the same time? If so, could you provide an example? Such
> an
> example is needed in several places in the lang ref (e.g. keydef,
Using
> keys and keyref) and maybe in the arch spec as well. And if so, then
> the
> above text needs further work.
> 
> > -----Original Message-----
> > From: Eliot Kimber [mailto:ekimber@reallysi.com]
> > Sent: Tuesday, November 24, 2009 11:53 AM
> > To: Michael Priestley; Bruce Nevin (bnevin)
> > Cc: dita
> > Subject: Re: [dita] conref.dita editorial review
> >
> > On 11/24/09 10:37 AM, "Michael Priestley" <mpriestl@ca.ibm.com>
wrote:
> >
> > > for 2:
> > >
> > > 2. The question embedded within the following paragraph:
> > >
> > >       A key is bound to the resource addressed by the
> > topicref or keyref
> > >       in which it is defined, if it is provided.
> > >       <!--What happens if  none is provided? It can't be
> > resolved? -->
> > >       The resource to which a key is bound may be a DITA
> > map or topic,
> > > or it
> > >       may be a non-DITA resource such as a graphic or an
> > object specified
> > >       by an external URI.
> > >
> > > A key is bound to the resource addressed by the topicref in
> > which it
> > > is defined. If no address is provided, the key is bound to the
> > > information provided by the topicref, such as a title and
metadata.
> >
> > This wording implies that the resource/subelement binding is
> > exclusive, but in fact it's both. I'm not sure how to express
> > that crisply--every time I've tried it comes out convoluted.
> >
> > That is, a key binds to any resource addressed by the
> > topicref as well as to any applicable subelements of the
> > topicref's topicmeta child.
> >
> > Cheers,
> >
> > Eliot
> >
> > --
> > Eliot Kimber
> > Senior Solutions Architect
> > "Bringing Strategy, Content, and Technology Together"
> > Main: 610.631.6770
> > www.reallysi.com
> > 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_workgr
> > oups.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