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] 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:pgrosso@ptc.com]
Sent: Monday, 2006 October 16 10:01
To: dita@lists.oasis-open.org
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:mpriestl@ca.ibm.com]
Sent: Sunday, 2006 October 15 21:41
To: dita@lists.oasis-open.org
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
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25


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