RE: [dita] Action: Eliot on lockmeta updates

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

It sounds like the value of @lockmeta determines which overrides the
other when there is a collision. If the correct interpretation is that
one overrides the other only in the collision cases, then it seems to me
that the default is 'both' for the non-collision cases--that is, the
union of the two sets of metadata, as Eliot says. 

	/Bruce

> -----Original Message-----
> From: Tony Self [mailto:tself@hyperwrite.com] 
> Sent: Tuesday, September 01, 2009 7:28 AM
> To: 'ekimber'; 'dita'
> Cc: dita-help@lists.oasis-open.org
> 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> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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 
> 
>