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


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



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