RE: [dita] Branch filtering elements: for discussion 4/15

I think ditvalref is good for referencing ditaval files and introducing those into the subtree scope. As combined with keyscope and other subtree context mechanisms we can perform a number of use cases clearly.

I think the tree duplication semantics of ditavalref are icing and I do not see the purpose for any of the dvr attributes yet (like to take them all out and add them back only if really necessary).

So if we eliminated that complexity, lets use our saved energy to tackle the specification of copies.

Explicit copy-to on its own cannot help and is limited anyway, so I propose implicit copy semantics (which seem ambiguous or not specified in the spec).

Implicit copy semantics would allow processors to create copies automatically as they encounter them and the identity of these copies is unspecified. If I topicref to the same topic twice within a publication then addressing those copies should be done with the best practice of binding a key to topicrefs that will be linked to. That combined with keyscope allows people to link to specific topics.

For example in mymap.ditamap

we have:

<map>

<topicref href="" keydef=”fooTopic” />

<topicref href="" keydef=”gooTopic” />

</map>

If we want to duplicate the tree we then have this (as opposed to two ditavalrefs) do the following which clearly establishes two contexts using existing DITA mechanisms:

</keywords>

</topicmeta>

</keydef>

<keyword>Windows</keyword>

</keywords>

</topicmeta>

</keydef>

foo.xml within the mac duplicate can be linked to using keyref=”mac.fooTopic”.

From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Robert D Anderson
Sent: April-08-14 12:29 PM
To: dita
Subject: [dita] Branch filtering elements: for discussion 4/15

Hi,

This is a reminder about the following thread, and 2 responses:
https://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201403/msg00160.html

In short: evaluating the <ditavalref> for branch filtering can result in new keys. For reasons explained in the thread, the proposed keynamePrefix and keynameSuffix elements can cause havoc in trying to resolve keys, while the alternative approach of adding/modifying key scopes treats this mechanism similar to any other key scope process. I've proposed removing the keyname* elements in favor of the scope ones; Eliot agreed and Chris gave an additional strong justification.

In addition to that, Chris made a good case to me that supplying the prefix/suffix for scope names is unnecessary; using the branch filter mechanism effectively creates a new scope anyway, so we could just a single element to name that new key scope. Following from that, it strikes me that if specifying a single scope name, we could also just add the existing keyscope attribute to <ditavalref>, but that presupposes that we only want the ability to rename (not modify) scopes. I'd be happy with either solution.

Thanks,

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)

dita message