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
