[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Action: Eliot on lockmeta updates
I wasn't trying to suggest that it apply in all cases. Perhaps the synonyms to consider for DITA 1.3 should be: "topic-wins-conflicts" for "yes" (the default); "map-wins-conflicts" for "no", and deprecate "yes" and "no". -Jeff > -----Original Message----- > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] > Sent: Tuesday, September 01, 2009 11:44 AM > To: Ogden, Jeff; dita > Cc: dita-help@lists.oasis-open.org > 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]