Re: [dita] conref and attribute overrides discussion

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

Michael Priestley wrote:

> 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 argued for and continue to argue for having the ignore conref target 
value for at least these reasons:

- It's parallel with "use conref target" and the existence of use conref 
target pretty much demands its inverse

- It allows required attributes to continue to be required as long as 
they also allow the two keywords. This at least makes it clear that some 
value has to be specified (and with XSD schemas can disallow null or 
space-only values).

- Requiring people to specify null or blank values is both a hack and 
not usefully better than simply suppressing an otherwise required 
attribute--it's harder to teach, non-obvious, and prone to error. For 
example, you couldn't detect the difference between an inadvertent 
failure to specify a real value and true author intent to ignore the 
target attribute (because, for example, an author inadvertently types a 
space into an attribute editor, changing the attribute from unspecified 
to specified with a space).

- The validity argument is weak given that in the cases where an 
attribute is required (the only case where this really matters), a null 
value is just as bad, for processing purposes, as an unspecified value. 
That is, while specifying a null value or space might be syntactically 
valid it cannot be *semantically valid* (or the attribute wouldn't be 
required in the first place).

The implication of this is that DITA-aware processors cannot assume that 
any attribute, regardless of its use specification, will be present in 
an instance. This is not a bad way to implement all XML applications 
since schemas can change without warning. Therefore I don't see the 
argument that with "missing attributes" a processor might try to get an 
attribute that it "knows" is required and fail to get on at all. That's 
true but not very compelling.

Regardless of whether the attribute is present the application still has 
to check for a null or space-only value anyway, so it doesn't really 
matter. Besides, it only requires one simple helper function to handle 
attribute getting for a DITA-aware processor:

public String getAttributeValue(Element elem, String attname) {
   if (elem.hasAttribute(attname)) {
      return elem.getAttribute(attname);
   }
   return "";
}

I would say that clarity and obviousness of the markup design should 
always be given weight over cost of implementation as long as the 
implementation cost is not huge (and in this case, making a check for 
attribute existence could not be considered huge, or even noticable).

The possible failure case is where both the conref source and target 
specify "ignore conref target", in which case the processor of the 
transcluded result has no usable value. But that case is functionally no 
different from having specified null values in both cases. In addition, 
any DITA-aware editor should disallow setting of an attribute to a 
conref-specific value if the element does not also specify conref, 
making it relatively hard to create this error condition. Likewise, a 
DITA validation application can both detect this case and validate the 
conrefed result.

Note that validating the conref result at the time the conref is created 
is useful but not sufficient since a new version of the conref target 
could be created at any time, making a previously-useful conref result 
non-useful.

Cheers,

Eliot

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com