OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]