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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]