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] Question about what it means when @format conflicts with actual format

Agreed. My point is that in the case where there is an explicit or inherited @format attribute that is incorrect, it should be treated as an error. The goal of the defaults for scope and format is to make the need to specify them explicitly extremely rare.


Chris Nitchie

(734) 330-2978




Follow us:






From: Bob Thomas <bob.thomas@tagsmiths.com>
Date: Monday, March 17, 2014 at 10:13 AM
To: Chris Nitchie <chris.nitchie@oberontech.com>
Cc: Robert D Anderson <robander@us.ibm.com>, dita <dita@lists.oasis-open.org>
Subject: Re: [dita] Question about what it means when @format conflicts with actual format

Now that file extensions can determine the implied value of the format attribute, it makes sense to support file-extension recognition for <topicref href="" instead of defaulting it to "dita".

Best Regards,
Bob Thomas

On Mon, Mar 17, 2014 at 6:02 AM, Chris Nitchie <chris.nitchie@oberontech.com> wrote:
I’d say this:

It is an error if the format of the content referenced by the @href attribute is different from that specified by the @format attribute, and processors SHOULD report the error. Additionally, processors MAY recover from the error by adjusting the processing algorithm for the referenced content to one appropriate for the actual format.


From: Robert D Anderson <robander@us.ibm.com>
Date: Thursday, March 13, 2014 at 6:37 PM
To: dita <dita@lists.oasis-open.org>
Subject: [dita] Question about what it means when @format conflicts with actual format

Jarno posed an interesting question about the @format attribute:
If the @format value specified in linking element conflicts with the format of the link target, what should processor behaviour be?

For example, if you have <topicref href="" format="html"/> and topic.dita is a DITA topic, should the processor throw an error or warning and keep processing the link using the format information in the target? Or, is a processor allowed to ignore topic.dita for e.g. key and conref processing, because the reference to it was HTML?

Another example, if you have <topicref href="" and the default format value is "dita", is a processor allowed to skip the map.ditamap for key space building and other map related processing?

Thus, is @format a processing hint for the processor and allows for optimizations like not trying to parse HTML as a DITA topic/map, or is it a processing constraint that forces a processor to treat a link in the way @format attribute defines the link target.

In a lot of my own DITA work, I've added special checks that throw errors for (to my users) common mistakes. For example, format="ditamap" when the target doesn't reference something with a ditamap extension, and any inherited non-dita format value when the extension is actually "dita". Most of the related processing uses the explicit value, rather than correcting, but the error gives authors a chance to correct things when that is not the right action.

I doubt that everybody does that. I would resist updating the spec to state that processors SHOULD or MUST ignore the stated format and use the actual format, but beyond that I think either clarification is probably legal within the constraints of DITA 1.3 -- that is, either it's a hint that processors can use for optimizations (up to author to get it right), or it's a constraint that says "this IS the format I'm declaring".

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)

Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype
Time zone: Mountain (GMT-7)

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