[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Should We Refine the Rules for Filename Generation for@chunk?
On 12/2/09 2:17 PM, "Kristen James Eberlein" <kris@eberleinconsulting.com> wrote: > I agree with Jeff. We cannot do anything more for DITA 1.2; we just need > to get the spec written and out the door. Please save your good ideas > for DITA 1.3 or later! Fair enough. There is a workaround since you can always set @copy-to to match the key. But I'm also wondering if the current language, which says "is determined as follows" should be relaxed to "should be determined as follows" so that alternative approaches are explicitly allowed? Cheers, E. > > Kris > > Ogden, Jeff wrote: >> We should not do this for DITA 1.2. We can consider it for DITA 1.3. >> >> -Jeff >> >> >>> -----Original Message----- >>> From: Eliot Kimber [mailto:ekimber@reallysi.com] >>> Sent: Wednesday, December 02, 2009 2:31 PM >>> To: dita >>> Subject: [dita] Should We Refine the Rules for Filename Generation for >>> @chunk? >>> >>> The current 2nd review draft says this in the ArchSpec topic on >>> Chunking: >>> >>> ----- >>> When creating new documents via chunk processing, the storage object >>> name or >>> identifier (if relevant) is determined as follows: >>> >>> - If an entire map is used to generate a single chunk (by placing to- >>> content >>> on the map element), the name is taken from the name of the map. >>> From the copy-to attribute, if the copy-to attribute is specified. >>> >>> - If copy-to is not specified and the by-topic policy is in effect, >>> >> the >> >>> name >>> is taken from the id attribute of the topic. >>> >>> - If copy-to is not speified[sic] and the by-document policy is in >>> effect, >>> the name is taken from the name of the referenced document. >>> ---- >>> >>> However, with keys, I think it would make sense to use the first or >>> only key >>> defined by the chunking topicref if there is one or, if the topicref >>> uses >>> keyref, the key referenced. >>> >>> That is, keys serve to define a map-global namespace of uses of topics >>> and >>> it would make sense to take advantage of those names in the chunk >>> >> case, >> >>> in >>> preference to a topic's ID, which is not necessarily unique in any >>> context >>> beyond its own document (and in my data sets, is almost never unique). >>> >>> That is, given this topicref: >>> >>> <topicref >>> keys="use-one-of-topic-x" >>> href="topic-x.dita" >>> chunk="to-content" >>> >>> ... >>> </topicref> >>> >>> I would expect the generated filename of the chunk to be >>> "use-one-of-topic-x.dita". >>> >>> Likewise, if I have this topicref: >>> >>> <topicref keyref="use-one-of-topic-x" >>> chunk="to-content" >>> >>> ... >>> </topicref> >>> >>> I would expect the generated filename to reflect the referenced key. >>> >>> Thus I propose to amend the above by adding new second and third >>> bullets: >>> >>> - If @keys is specified, the name is taken from the first key name in >>> the >>> @keys value. >>> >>> - If @keyref is specified, the name is taken from the key name >>> specified by >>> @keyref. >>> >>> These two additions would effectively make the use of keys an implicit >>> @copy-to when using @chunk. >>> >>> Cheers, >>> >>> E. >>> >>> -- >>> 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_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 >> >> >> >> >> > -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 610.631.6770 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]