conref and attribute overrides discussion

[Michael Priestley <mpriestl@ca.ibm.com>]

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