[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Action: Eliot on lockmeta updates
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. /Bruce > -----Original Message----- > From: Tony Self [mailto:tself@hyperwrite.com] > Sent: Tuesday, September 01, 2009 7:28 AM > To: 'ekimber'; 'dita' > Cc: dita-help@lists.oasis-open.org > 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. > > Regards > > 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 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_workgr > oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]