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] ITEM: Meaningful Values for type= on xref and topicref

Comments below.




> -----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]