[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Action: Eliot on lockmeta updates
Hi Eliot On the DITA Help Subcommittee, we've been discussing a metadata element to contain context hooks for context-sensitive user assistance (Help) applications. The element (we're calling it ua-context) might be defined in either the map or the topic. We've realised we have a need for an attribute to specify whether a context hook in the map takes precedence over a hook in the topic, as we could envisage scenarios where either would be a user requirement. Our first cut of the name for this attribute was @yield-to-topic, which would only be used in the map topicref topicmeta. The default would be false, meaning the map trumps the topic. An example of mark-up within a map's topicref topicmeta might be: <ua-context id="ab12" context-id="1234" context-string="idh_filesave" yield-to-topic="true" /> Reading your post about @lockmeta, it occurred to me that our @yield-to-topic might be serving a similar purpose. From your understanding of @lockmeta, do you think we could use it? Our latest discussions on the issue seem to indicate we need three "states" for our @yield-to-topic: true, false and both. The both setting would mean that both topic and map context hooks would be applied to the output. Regards Tony Self -----Original Message----- From: ekimber [mailto:ekimber@reallysi.com] Sent: Tuesday, 1 September 2009 2:18 PM To: dita Subject: [dita] Action: Eliot on lockmeta updates In thinking about what lockmeta is all about, I think the issue I had was that the entry for topicmeta left a lot of things implicit that need to be made explicit. I think the architectural intent is that for a given topicref to a topic there is an effective <metadata> set that is the union of the topicref's metadata and the topic's metadata. The result of that union then becomes the effective metadata for both the topicref and the topic, in that use context. The author decision is whether the topicref's or the topic's metadata should take precedence when constructing the effective value of the metadata. Per the current language of the topicmeta element definition: "Indicates whether any of the meta information should be replaced by meta information in the referenced topic. If the value is yes, the information inside <topicmeta> should not be replaced with information from the topic." This means, I think, that when @lockmeta="yes", then the topicref's metadata takes precedence and when @lockmeta="no", the topic's metadata takes precedence. What the current spec doesn't say is whether "yes" or "no" is the default. I would expec the default to be "yes", namely that the topicref's metadata takes precedence unless you say otherwise. If this understanding is correct, then the current topicmeta topic needs to be reworked to say this more or less as I have here. In addition, the still-to-be-written topic on Attribute and metadata inheritance in the Arch Spec needs to include a discussion of this behavior as well. Cheers, Eliot ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]