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