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