[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Deprecating @copy-to
Given that each ditaval can potentially introduce its own unique
version of any conditioned topic, it seems to me that this makes
the ditaval file the appropriate place to declare a "namespace"
for topics filtered by that particular ditaval. A new metadata
value added to the ditaval DTD would declare that val file's
namespace that would be prepended to filenames of topics modified
by that ditaval set (and only for modified topics in order not to
create duplicates from unmodified topics). In branch filtered cases, the namespaces can aggregate, or last
one wins--not sure which is better. But this would ensure that all
filtered topics are still uniquely named. Some users may prefer specific filenames for these conditions, in
which case namespacing from the ditaval won't solve that need. If
documents are to be published in an interoperable manner by
another company, then the naming method needs to be consistent
across tools. In Web publishing, the method of choice is a
separate slug for each published variant of the content. This
dependency of the process that produced the variant output on the
naming of that output means that the ditaval file should be the
place where each variant name (or slug) is declared, or at least
keyed from. Here, I think that the declared namespace in a ditaval
could also serve as a key to a particular set of keydefs (or their
context map) where the keydef serves as the place where that
particular slug value is bound to the actual resource. A topic
would have a different keydef/slug for each ditaval where explicit
naming is preferred (effectively supplanting the copy-to intent). Summary: A ditaval with a namespace value will normally append that namespace to any topic it affects. Alternatively, that namespace also keys that ditaval to keydefs that provide alternate output slug names for the touched renditions. (This is not standard for keydefs held in a map, but it works fine for a mapless dynamic publishing environment, and may inform on the need for being able to group keydefs independently of a map.) This proposal also eschews use of metadata within the topic as
the source for the slugname since the condition requiring the slug
is created by the processing context and should be changed in that
context without having to edit the topic for each presumed new SEO
campaign.
Don R. Day
Founding Chair, OASIS DITA Technical Committee (current version: DITA 1.3) LinkedIn: donrday Twitter: @donrday About.me: Don R. Day Skype: don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?" --T.S. Eliot On 6/7/2016 11:13 AM, Eliot Kimber
wrote:
-
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]