RE: [dita] Action: Eliot on lockmeta updates

Eliot,

I think what you outline in your note about @lockmeta makes sense.

The processing supplied default for @lockmeta on a topicref in a map is "yes" as you suggest in your note:

From the DITA 1.1 Architecture Spec.:

Shared metadata elements, and the lockmeta attribute

You can associate topic metadata with a topic or branch of topics in a map. By default metadata in the

map supplements or overrides metadata in the topic. If the lockmeta attribute is set to ″no″, then the

metadata in the map will not take precedence over the metadata in the topic, and conflicts will be

resolved in favor of the topic.

What has always been unclear to me about lockmeta is:

· How do @lockmeta and @locktitle interact? Particularly now that we have <navtitle> within <topicmeta>?

· Does @lockmeta just apply to elements that are contained within topicmeta and its specializations or does it apply to other types of metadata too (to metadata attributes on the topicref tag for example)?

· How does this work for <shortdesc> within <topicmeta>? Is the <shortdesc> in the map replaced by <shortdesc> from the topic unless @lockmeta is set to “yes”? It would seem to be what is called for if <shortdesc> within <topicmeta> is metadata like any other metadata. How does this jibe with our recent discussion of <shortdesc> in maps?

This note from the DITA 1.1 Architecture Spec. seems to imply that <shortdesc> isn’t special:

The map metadata also includes a short description and alternate titles, which can override their

equivalents in the content. In sum, the map can override or supplement everything about a topic except

its content (in the topic’s body element) and primary title.

But we know that the DITA 1.1 Architecture Spec. seems to contradict itself wrt <shortdesc> in maps.

-Jeff

> -----Original Message-----

> From: ekimber [mailto:ekimber@reallysi.com]

> Sent: Tuesday, September 01, 2009 12:18 AM

> 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_workgroups.php

dita message