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


Help: OASIS Mailing Lists Help | MarkMail Help

dita-help message

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

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. 


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

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.



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]