[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Action: Eliot on lockmeta updates
My question was whether the yes/no value applies only in the collision cases, and @lockmeta takes effect only for a "Collision case" = "when a given metadata value can only occur once and occurs in both the topic and topicref metadata". You're suggesting that it applies in all cases. /Bruce > -----Original Message----- > From: Ogden, Jeff [mailto:jogden@ptc.com] > Sent: Tuesday, September 01, 2009 11:00 AM > To: dita > Cc: dita-help@lists.oasis-open.org > Subject: RE: [dita] Action: Eliot on lockmeta updates > > But the only legal values for @lockmeta in DITA 1.0, 1.1, and > 1.2 are "yes" and "no". > > In DITA 1.3 it might be good to add synonyms of > "mapoverrides" for "no" > and "topicoverrides" for "yes" and deprecate "yes" and "no". > > -Jeff > > > -----Original Message----- > > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] > > Sent: Tuesday, September 01, 2009 10:39 AM > > To: tself@hyperwrite.com; ekimber; dita > > Cc: dita-help@lists.oasis-open.org > > 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 > > > > > > > > > > > --------------------------------------------------------------------- > > 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 > > > --------------------------------------------------------------------- > 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]