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
