OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
Back to discussions
Expand all | Collapse all

Action: Eliot on lockmeta updates

  • 1.  Action: Eliot on lockmeta updates

    Posted 09-01-2009 04:18 
    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


  • 2.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-01-2009 11:27 
    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:


  • 3.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-01-2009 14:39 
    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


  • 4.  Re: [dita] Action: Eliot on lockmeta updates

    Posted 09-01-2009 14:50 
    On 9/1/09 9:38 AM, "Bruce Nevin (bnevin)"


  • 5.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-01-2009 15:09 
    Semantically, @yield-to-topic is the converse of lockmeta, which implies
don't yield to topic. The name seems to affect usability only, you can
do the same things with either. Question is what values are needed for
your four cases.

A now moot nit:

> That's not quite what I meant: I meant that the metadata is 
> *always* unioned. The only question is what to do when a 
> given metadata value can only occur once and occurs in both 
> the topic and topicref metadata?

I *think* this says the same thing. "Collision case" = "when a given
metadata value can only occur once and occurs in both the topic and
topicref metadata" and "the default is 'both' for the non-collision
cases" = "Always unioned" (where "always" is subject to the provision
for the collision cases).

	/Bruce

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 6.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-02-2009 04:35 
    There is perhaps a fifth case to add to Eliot's four.

>>>>
1. The topicref's metadata is used exclusively as the effective metadata for
the topic and the topicref.

2. The topic's metadata is used exlclusively as the effective metadata for
the topic and the topicref.

3. The topicref's and topic's metadata are merged, with metadata items from
the topicref overriding the same metadata items from the topic (where "same"
may not be clearly definable in all cases, but that's a separate issue).

4. The topicref's and topic's metadata are mered, with metadata items from
the topic overriding the same metadata items from the topicref.
<<<<

5. The topicref's and topic's metadata are merged, with metadata items from
both the topicref and the topic being used (where multiple metadata items
are valid).


For example, with ua-context elements of:

Topicref ->


  • 7.  Re: [dita] Action: Eliot on lockmeta updates

    Posted 09-02-2009 04:45 
    I'm not sure this is really a distinct case because "same" is not currently
well defined for metadata, especially where multiple instances are allowed
(e.g., <data>).

For example, should two <data> elements with the same @name value be
considered the same or different?

Or said another way: the only way your new case 5 could make sense is if you
can define, on a per-metadata-item-instance basis whether it replaces,
defers to, or augments instances of the same item, where "sameness" may
itself have to be defined on a per element-type basis.

The 1.2 language is (and must continue to be) pretty fuzzy on this issue. It
will be a task for 1.3 to try to make it less fuzzy.

My guess would be that we need to add one or more new attributes to control
the merging behavior and then expect specializers to set defaults so that
the intent of the specialization designer is as clear as it can be.

Cheers,

Eliot 

On 9/1/09 11:36 PM, "Tony Self" </data></data>


  • 8.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-02-2009 04:35 
    There is perhaps a fifth case to add to Eliot's four.

>>>>
1. The topicref's metadata is used exclusively as the effective metadata for
the topic and the topicref.

2. The topic's metadata is used exlclusively as the effective metadata for
the topic and the topicref.

3. The topicref's and topic's metadata are merged, with metadata items from
the topicref overriding the same metadata items from the topic (where "same"
may not be clearly definable in all cases, but that's a separate issue).

4. The topicref's and topic's metadata are mered, with metadata items from
the topic overriding the same metadata items from the topicref.
<<<<

5. The topicref's and topic's metadata are merged, with metadata items from
both the topicref and the topic being used (where multiple metadata items
are valid).


For example, with ua-context elements of:

Topicref ->


  • 9.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-01-2009 15:01 
    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


  • 10.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-01-2009 15:44 
    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


  • 11.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-01-2009 16:05 
    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


  • 12.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-01-2009 11:27 
    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:


  • 13.  RE: [dita] Action: Eliot on lockmeta updates

    Posted 09-01-2009 14:54 
    










    


    Eliot,
    


    


    I think what you outline in your note about @lockmeta makes
sense.
    


    


    The processing supplied default for @lockmeta on a
topicref in a map is "yes" as you suggest in your note:
    


    


    From the DITA 1.1 Architecture Spec.:
    


    


                    Shared metadata
elements, and the lockmeta attribute
    


    You can associate
topic metadata with a topic or branch of topics in a map. By default metadata
in the
    


    map supplements
or overrides metadata in the topic. If the lockmeta attribute is set to ″no″, then the
    


    metadata in the
map will not take precedence over the metadata in the topic, and conflicts will
be
    


    resolved in favor of the topic.
    


    


    What has always been unclear to me about lockmeta is:
    


    


    ·        
How do @lockmeta and @locktitle interact? 
Particularly now that we have <navtitle> within <topicmeta>?
    


    


    ·        
Does @lockmeta just apply to elements that are
contained within topicmeta and its specializations or does it apply to other
types of metadata too (to metadata attributes on the topicref tag for example)?
    


    


    ·        
How does this work for <shortdesc> within
<topicmeta>?  Is the <shortdesc> in the map replaced by
<shortdesc> from the topic unless @lockmeta is set to “yes”?  It
would seem to be what is called for if <shortdesc> within
<topicmeta> is metadata like any other metadata. How does this jibe with
our recent discussion of <shortdesc> in maps? 
    


    


    This note from the DITA 1.1
Architecture Spec. seems to imply that <shortdesc> isn’t special:
    


    The map metadata
also includes a short description and alternate titles, which can override
their
    


    equivalents in
the content. In sum, the map can override or supplement everything about a
topic except
    


    its content (in the topic’s body element)
and primary title.
    


    


          But we know that the DITA
1.1 Architecture Spec. seems to contradict itself wrt <shortdesc> in
maps.
    


    


       -Jeff
    


    


    > 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content