OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
  • 1.  DITA v1.2 Review | @keys in a conref

    Posted 09-01-2010 04:56
    
    
    
    
    
    
    
    
    
    
    

    I am not able to identify the use of @keys at an element that is actually a conref. In case of a conref, the @href may be generally missing as that shall be derived from the referenced element.

    Say for example, in a map there is topicref element which is actually a conref to a topicref element in another map.

    In map1.ditamap:

    <map>

             …….

             <topicref id=”tr-01”  keys=”TR01” href=”abc.dita”/>

             …….

    </map>

    In map2.ditamap:

    <map>

             …….

             <topicref id=”tr-02”  keys=”TR02” conref=”map1.ditamap#tr-01”/>

             …….

    </map>

    What shall the key TR02 resolve to? As I understand, that resolves to nothing.

    Also, is there any specific use of such a key in a conref element, apart from defining a key that points to nothing. I am not ruling out the cases where such an element carries an @href as well. But in that case, the purpose of conref is undermined.

    Regards,

    Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com



  • 2.  Re: [dita] DITA v1.2 Review | @keys in a conref

    Posted 09-01-2010 05:06
    In your example, the effective element after conref resolution is:
    
    


  • 3.  RE: [dita] DITA v1.2 Review | @keys in a conref

    Posted 09-02-2010 08:51
    I thought we don't use conref, topicsetref, keyref & conkeyref resolution for determining the keyspace. For keyref & conkeyref, it is very obvious that since they depend on keyspace, these shall not be resolved until the keyspace is determined completely. But for conref & topicsetref, it is possible that these elements (prior to resolution), have key definitions on themselves or on any of their descendants.
    
    That brings the following questions to my mind:
    1) For determining keyspace, should the conref & topicsetref be resolve?
    2) If (1) is yes, should the key definitions be included from any of the descentants of the conref/topicsetref target/referenced element (for conref range this shall also means siblings from the target)
    3) if (1) is no, should the key definitions be included from any of the descentants of the conref/topicsetref referencing element
    
    
    Regards,
    Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com
    
    
    


  • 4.  Re: [dita] DITA v1.2 Review | @keys in a conref

    Posted 09-02-2010 11:09
    For the purpose of constructing a key space, the system should resolve any
    non-key-based conrefs in the maps, determine the effective map tree, and
    then construct the key space. Key-based conrefs between maps and maps or
    topicrefs and topicrefs cannot be resolved until the key space has been
    constructed and therefore cannot affect the key space.
    
    Once the key space has been constructed then all remaining key-based conrefs
    can be resolved, which determines the final map tree, but cannot change the
    effective key space. Because any use of a key for conref must ultimately use
    an href to address the document that contains the conref target (in this
    case, map documents for the case of topicref-to-topicref conrefs), then
    every map document will be part of the map tree. The only question is
    *where* in the map tree the map's topicrefs occur for the purpose of
    determining the key space.
    
    That is, you could have a key-based conref of a key-defining topicref that
    occurs before the direct reference of the map containing that key
    definition. If a definition of the same key name occurs between the conref
    and the inclusion of the map containing the conref target topicref, then the
    intervening key definition will be the effective definition (because of the
    precedence rules of key definitions).
    
    Said simply, only directly-conreffed (that is addresed by hrefs) topicrefs
    and maps can be resolved during key space construction. Or even more simply,
    only directly-addressed maps contribute to the key-space-defining map tree
    (which subsumes direct conrefs of topicrefs since a direct conref of a
    topicref must first address the map document that contains the topicref,
    adding that map to the effective key space map tree).
    
    In practice this should not be an issue because there is no good use case
    that I can think of for conreffing topicrefs and this very limitation would
    further argue against using conrefs in maps, given that there are other
    facilities for combining map components into composite maps.
    
    Note that the DITA 1.x spec *cannot* mandate a processing sequence because
    of backward compatibility issues (see the non-normative interoperability
    appendix, which explains some of the issues around this fact). So whether
    conref resolution is performed before or after key space construction is up
    to processors, but since keyref is an entirely new feature one hopes that
    processors will implement it consistently.
    
    Cheers,
    
    Eliot
    
    On 9/2/10 3:50 AM, "Tarun Garg" 


  • 5.  RE: [dita] DITA v1.2 Review | @keys in a conref

    Posted 09-04-2010 06:38
    Now with this understanding, suppose we have two maps as follows:
    
    Map1.ditamap:
    =============
    
       
    
    
    Map2.ditamap:
    =============
    
       
    
    
    
    Now for Map1.ditamap, the keyspace shall be as follows:
    
    Key	|	Target
    ==================
    A	|	1.dita
    M2	| 	b.dita
    M22	| 	b22.dita
    B	| 	c.dita
    M33	| 	c33.dita
    M4	| 	d.dita
    M44	| 	d44.dita
    D	| 	map2.ditamap#tr05
    M55	| 	e55.dita
    
    - Keys C & E are ignored due to conref & topicsetref resolution.
    - Key M3 is not there as due to conref resolution key B; the already existing @keys value gets used.
    - Key M5 is not there as due to topicsetref resolution key D; the already existing @keys value gets used.
    
    Please correct me if I am getting it wrong somewhere.
    
    Regards,
    Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com
    
    
    


  • 6.  Re: [dita] DITA v1.2 Review | @keys in a conref

    Posted 09-04-2010 12:02
      |   view attached

    Attachment(s)