conref and attribute overrides discussion

Do we have updated DITA 1.1 DTDs (and XSDs) with the latest 
conref attribute value additions?
 
paul


  
  
  From: Grosso, Paul [mailto:]
Sent: Monday, 2006 October 23 11:52
To: 
  
Subject: RE: [dita] conref and attribute 
  overrides discussion


  
  At last week's telcon, we accepted wording for conref 
  attribute handling with one outstanding issue--the 
wording:
   
  If the target element has a conref attribute specified, 
  the above rules should be applied recursively with the resolved element 
  from one source/target combination becoming the source element for the 
  next source/target combination. 
   
  could be taken to imply processing down the conref 
  chain whereas we decided it would be left to the implementation whether 
  processing goes up or down the chain.
   
  Therefore, I'm suggesting the above paragraph be 
  replaced with that below:
   
  If the target element has a conref attribute specified, 
  the above rules should be applied recursively with the resolved element 
  from one source/target combination becoming  one of the two  elements participating in  the next 
  source/target combination. 
   
  paul

  
    
    
    From: Grosso, Paul [mailto:]
Sent: Tuesday, 2006 October 17 09:22
To: 
    
Subject: RE: [dita] conref and attribute 
    overrides discussion


    
    In case anyone's actually listening, here is an 
    updated suggesting for wording (with some corrections and 
    additions):
     
    
    The resolved element's attribute 
    specifications consists of the 
    following:
    1.  All attributes as specified 
    on the source element unless the specified value is 
    "-dita-use-conref-target"
    2.  All attributes as specified 
    on the target element except:
       a.  the id 
    attribute
       b.  any attribute 
    also specified on the source element such that its specified value (on the 
    source element) is not "-dita-use-conref-target"
    Note that the only times  the resolved element 
    would include an attribute whose specified value is 
    "-dita-use-conref-target" is when  the target element had that 
    attribute specified with the "-dita-use-conref-target" value  and the source element either had no specification for 
    that attribute or had it specified with the "-dita-use-conref-target" value. 
    If the final resolved element (after the complete resolution of any conref 
    chain) has an attribute with the "-dita-use-conref-target" value, that 
    should be treated as equivalent to having that attribute 
    unspecified.
    Also note that a given attribute value on the 
    resolved element comes in its entirety from either the source or 
    target; the 
    attribute values of the target and 
    source for a given attribute are never additive, even if the property (such 
    as the audience type) takes a list of 
    values.
    If the target element has a conref 
    attribute specified, the above rules should be applied recursively with 
    the resolved element from one source/target combination becoming the 
    source element for the next source/target combination. 
    [I 
    removed "down the chain" from the above paragraph. I noticed that Michael 
    had conref chain processing going up the chain whereas I had it going down 
    the chain. We did not discuss this at the telcon, but I couldn't come up 
    with any situation where the direction of processing the chain made a 
    difference to the end result, so I decided we could leave that up to the 
    implementation and therefore didn't need to mention that in the spec. If 
    anyone can come up with a case where the direction makes a difference, 
    please let us know.]
     
    Finally, since we're talking so much about combining attributes in 
    this section, it may be worth adding a note at the end of this section 
    making it clear that the content of target elements is always ignored, 
    e.g.:
     
    The content 
    of the target element always completely replaces the content of the source 
    element. 
    
paul
    
      
      
      From: Grosso, Paul 
      [mailto:]
Sent: Monday, 2006 October 16 
      10:01
To: 
Subject: RE: 
      [dita] conref and attribute overrides discussion


      
      Though we're not always consistent, I think we tend 
      toward the use of hyphens to separate words in attribute names and values, 
      so I'd suggest we use "-dita-use-conref-target" to make the special value 
      easier to read.
       
      I'm not sure what we decided with respect to an id 
      attribute on the source element. Michael's Agreed wording implies such an 
      id would end up on the resulting element, but there are no examples 
      showing it. I'm assuming we would maintain the id on the source 
      element.
       
      Here's how I would word the last paragraph of the 
      "Content reference attribute" section of the Arch spec to reflect our 
      current agreement on merging attributes:
       
      The resolved element's attribute specifications will consist of the 
      following:
       
      1.  All attributes as specified on the source element unless 
      the specified value is "-dita-use-conref-target"
      2.  All attributes as specified on the target element 
      except:
         a.  the id attribute
         b.  any attribute also specified on the source 
      element such that its specified value (on the source element) is not 
      "-dita-use-conref-target"
       
      Note that the only time the resolved element would include an 
      attribute whose specified value is "-dita-use-conref-target" is when both 
      the source and target element had that attribute specified with the 
      "-dita-use-conref-target" value.
       
      If the target element has a conref attribute specified, the above 
      rules should be applied recursively down the conref chain with the 
      resolved element from one source/target combination becoming the 
      source element for the next source/target 
      combination.
       
      Michael has captured most of the open issues, though 
      Don did raise the issue of existing content that uses the null value trick 
      employeed by the tool kit (though never documented in the spec) to 
      accomplish what the proposed "-dita-use-conref-target" value will now 
      do. According to the newly suggested wording, an href="" on the source 
      will result in a resolved element with a null href. What we said on the 
      telcon was that this was just going to have to be another migration 
      issue.
       
      As far as adding another special value to allow the 
      "deletion" of attributes on the target, while I can see the usefulness, 
      given the potential problems and the fact that this is an edge case, I'd 
      suggest we leave consideration of this to another 
      release.
       
      paul
  
        
        
        From: Michael Priestley 
        [mailto:]
Sent: Sunday, 2006 October 15 
        21:41
To: 
Subject: [dita] 
        conref and attribute overrides discussion


        
In attendance:
France Baril, Robert Anderson, Eliot 
        Kimber, Paul Grosso, Don Day, and Michael Priestley 

Agreed:
- 
        attributes of both the target element and the source element are added 
        to the result element, except for the id of the target
- if the same attribute is present on both 
        elements, the attribute of the source element is preserved in preference 
        to the attribute of the target, unless the value of the source element's 
        attribute is "-ditauseconreftarget"

Example (simple):
<p 
        platform="x" conref="#a/b"/>
<p id="b" audience="y">abc</p>
results in 
<p platform="x" audience="y" 
        conref="#a/b">abc</p>
(the audience attribute is copied over, the id attribute is not, 
        all attributes on the source element are preserved)

Example (with override):
<p platform="x" conref="#a/b"/>
<p id="b" 
        platform="y">abc</p>
results in 
<p 
        platform="x" conref="#a/b">abc</p>
(the platform attribute on the source overrides 
        the platform attribute on the target, since presumably the person 
        creating the conref has more knowledge of which platforms apply in the 
        new context)

Example (with 
        override in other direction):
<image href="-ditauseconreftarget" conref="#a/b"/>
<image id="b" 
        href="abc.gif"><alt>it's an abc 
        image</alt></image>
results in
<image 
        href="abc.gif"><alt>it's an abc 
        image</alt></image>
(the conref author cannot simply omit the href attribute since it 
        is required by the doctype - thus the only way to usefully conref images 
        is to provide this override capability)

In cases of a conref chain, (that is, an element 
        that conrefs to an element that conrefs to an element etc.), the above 
        rules still apply and should be applied recursively starting with the 
        final target.
Example:
<p platform="a" conref="#a/b" 
        />
<p id="b" platform="x" 
         audience="y" conref="#a/c" />
<p id="c" audience="z">something</p>
results in
<p platform="a" audience="y" 
        conref="#a/b">something</p>
(platform conflict resolved in favour of first source element; 
        audience conflict resolved in favour of second source element, conref 
        attribute of first source element is preserved)

DTD/Schema impact:
- any attributes that currently have enumerated 
        values would need to have the new value "-ditauseconreftarget" added to 
        the enumeration, to allow for specializations in which the attribute is 
        made required

Unresolved:
- do we need 
        another value called "-ditaignoreconreftarget", for cases where we want 
        to get rid of an attribute on the conref target?
- issue is that would allow the deletion of 
        required attributes during conref, which breaks the conref promise of 
        valid output; also, creates some usability pain for attributes with 
        enumerated values, which would now have two values that are rarely used 
        instead of just one
- 
        alternative would be to say that the author of the conref source element 
        cannot delete attributes of the target element, but at most can add 
        blank values or strings of spaces to override values of the target; this 
        would preserve the conref promise of valid output, but at some cost to 
        usability in this edge case

I hope that caught the main points of the discussion - it was a 
        productive meeting, thanks much to those involved, let's see if we can 
        keep the discussion going on the list.

Thanks,

Michael Priestley
IBM DITA Architect and Classification Schema 
        PDT 
      Lead

http://dita.xml.org/blog/25