OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Implications of type= attribute for xref element

The type attribute becomes useful when scope=external or scope=peer or format=(something other than dita). IE, there are legitimate cases where you have an xref pointing to something that cannot be inspected by the processor to determine the target type.

It seems reasonable though to say that when the type is unspecified it should be determined by inspecting the target if possible, and only default to topic if the target cannot be inspected for some reason.

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead

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

01/02/2007 06:00 PM

[dita] Implications of type= attribute for xref element

In reviewing how the xref element is defined, I notice that the type=
attribute is defined such that if unspecified, the xref is to be treated
as though the type= value was "topic".

However, this does not seem like appropriate or necessary behavior for
the simple reason that the implicit type can be determined from the
target of the xref.

At a minimum I would think that the default should say something like
"Determined by the element type or class of the xref target or "unknown"
if cross reference target cannot be resolved." (Or possibly "topic" if
the cross reference target cannot be resolved--both are equally useful

It's not even clear to me why this attribute exists since normally any
styling of references based on target element type (as opposed to
author-defined choices like the form of the generated reference with
regard to title or page number or whatever) would be determined
dynamically at the time the output is generated.

I suspect that the current markup design reflects processing in which it
is expected that href URLs will get blindly translated into output
target URLs. However, that approach cannot be a general solution. In the
general case, the output processor processing the reference has to be
able to resolve the target in order to know how to construct the
resulting link artifact in the output result. In that case, something
like the type= attribute is entirely redundant and will often result in
a mismatch between the specified (or defaulted value) and the actual target.

The definition of the semantics of xref is fuzzy enough that it's not
100% clear what processors are required to do if type= doesn't match the
actual type of the target, but implementors could certainly argue that
they are obligated to apply the type="topic" behavior when type= is
unspecified, even when they can tell the actual type perfectly well.

For example, in the likely case that I've built my DITA processor to do
just what I've described above, removing the need for the type=
attribute, I then have to either force my authors to still specify a
value (even though it's not useful), specify a (meaningless) default
value that my application recognizes as "ignore this value", ignore the
specification's definition of what an implied value means and *not*
treat the xref target as type "topic" when the target is in fact not a
topic, or build extra authoring tools that set the type value when the
link is authored and then make sure it is accurate if the link target is


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]