[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] ITEM: Meaningful Values for type= on xref and topicref
Comments below. -Jeff > -----Original Message----- > From: Eliot Kimber [mailto:ekimber@reallysi.com] > Sent: Friday, July 10, 2009 10:12 AM > To: Ogden, Jeff; dita > Subject: Re: [dita] ITEM: Meaningful Values for
type= on xref and > topicref > > I'm happy with with Jeff's modifications to the
language as I proposed it. [JeffO:] Whew! > Jeff asks: > >> Since the current list consists of unqualified
element names (fig, >> table, li, fn, …). Do we want/need to
require processors to support the >> qualified names for items on this list or should
we add the qualified names to the >> list so that processors are required to support
both? Are we comfortable >> putting new requirements on processors at this
late stage of DITA 1.2? > > In this context, what does "support" mean?
[JeffO:] I think we
mean processors MUST recognize > I think the current language is a bit
underspecified, [JeffO:] I agree, but I’m
not so sure that what would be specified here doesn’t fall more into the
realm of output processing behavior that we don’t often specify.
There are a few specific exceptions, such as “fn”. > since I think that the processing
referred to by > the current paragraph is about xref resolution and
reflection, that is, > generating meaningful link anchors for xrefs. [JeffO:] Isn’t
this section more general than that and isn’t @type used with “linking”
elements other than xref? I guess sub-element references are limited to xref or
possibly xref and non-DITA references. > > However, the processing I've been focusing on for
@type is simply > validating that the reference target matches the
@type value. That > processing is completely orthogonal to
xref or link processing. [JeffO:] I didn’t
think that validation was required here. There is already language that says “an
implementation may (but need not) give an error message, and may (but need not)
recover from this error condition by using the type attribute value”. > > I think it would be better to separate these two
processing aspects so we > can make the conformance requirements clear. [JeffO:] I agree. > In particular, the current > statement about supporting type isn't really about
@type validation but > about xref processing, and that language belongs in
the defintion of > <xref>, not @type. [JeffO:] You could move
it, but I also think that the current wording with a few fix ups of the sort we’ve
been talking about is fine where it is. > Moving it there would make it clear that the > conformance and processing
requirements there are a function of the > type referenced, not the validation of
@type-defined constraints. > > In the @type attribute itself, the question becomes
"are conforming > processors required to validate @type at all?" > > I think the answer is "yes". [JeffO:] I disagree because
of the existing wording that says “an implementation may
(but need not) give an error message, and may (but need not) recover from this
error condition by using the type attribute value”. > But since current behavior is that the > processing for ambiguous @type references is
undefined, I think its > reasonable to say that, for DITA 1.2, processors are
not required to > support qualified names in @type values and can
either ignore them > entirely or treat them
as unqualified names. [JeffO:] I think we
need to split the question into what are processors REQUIRED to recognize and
what are they REQUIRED to do once something is recognized. [JeffO:] I think
processors MUST recognize the unqualified names that are already on the list,
that they SHOULD recognize the qualified names for the unqualified names
already on the list, and that we should say that it is likely that processors
will be REQUIRED to recognize the qualified names in a future version of the
DITA specification. [JeffO:] I don’t
think we should add anything new about what processors MUST or SHOULD do when
they recognize a name beyond what was already included in the DITA 1.1 spec. or
what is said in a previously approved DITA 1.2 proposal. [JeffO:] And validation
of @type values against referenced types should continue to be allowed, but not
required. > > Cheers, > > E. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]