[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] conref and attribute overrides discussion
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]