RE: [dita] Action: Eliot on lockmeta updates

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

Semantically, @yield-to-topic is the converse of lockmeta, which implies
don't yield to topic. The name seems to affect usability only, you can
do the same things with either. Question is what values are needed for
your four cases.

A now moot nit:

> That's not quite what I meant: I meant that the metadata is 
> *always* unioned. The only question is what to do when a 
> given metadata value can only occur once and occurs in both 
> the topic and topicref metadata?

I *think* this says the same thing. "Collision case" = "when a given
metadata value can only occur once and occurs in both the topic and
topicref metadata" and "the default is 'both' for the non-collision
cases" = "Always unioned" (where "always" is subject to the provision
for the collision cases).

	/Bruce

> -----Original Message-----
> From: ekimber [mailto:ekimber@reallysi.com] 
> Sent: Tuesday, September 01, 2009 10:50 AM
> To: Bruce Nevin (bnevin); tself@hyperwrite.com; dita
> Cc: dita-help@lists.oasis-open.org
> Subject: Re: [dita] Action: Eliot on lockmeta updates 
> 
> On 9/1/09 9:38 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:
> 
> > 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.
> 
> That's not quite what I meant: I meant that the metadata is 
> *always* unioned. The only question is what to do when a 
> given metadata value can only occur once and occurs in both 
> the topic and topicref metadata?
> 
> But now that Bruce brings it up, perhaps that's not the right 
> interpretation?
> 
> I think there are these possible cases:
> 
> 1. The topicref's metadata is used exclusively as the 
> effective metadata for the topic and the topicref.
> 
> 2. The topic's metadata is used exlclusively as the effective 
> metadata for the topic and the topicref.
> 
> 3. The topicref's and topic's metadata are merged, with 
> metadata items from the topicref overriding the same metadata 
> items from the topic (where "same"
> may not be clearly definable in all cases, but that's a 
> separate issue).
> 
> 4. The topicref's and topic's metadata are mered, with 
> metadata items from the topic overriding the same metadata 
> items from the topicref.
> 
> In addition, there appears to be a separate case, where you 
> want to control the behavior for individual metadata items, 
> as in the help case.
> 
> That suggests that at a minimum the @lockmeta attribute is 
> underspecified, since "yes", "no", and no value are not 
> sufficient to cover these four cases or the intended behavior 
> does not include all of these cases or some of these cases 
> are already covered by other behavior definitions.
> 
> Cheers,
> 
> E.
> 
> 
> ----
> 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> 
> 
>