Action: Eliot on lockmeta updates

[ekimber <ekimber@reallysi.com>]

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>