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

Chris Nitchie

(734) 330-2978



www.oberontech.com

Follow us:

 

 

From: Bob Thomas <>

Date: Monday, March 17, 2014 at 10:13 AM

To: Chris Nitchie <>

Cc: Robert D Anderson <>, dita <>

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

Chris

Chris Nitchie

(734) 330-2978



www.oberontech.com

Follow us:

 

 

From: Robert D Anderson <>

Date: Thursday, March 13, 2014 at 6:37 PM

To: dita <>

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 () or Skype

Time zone: Mountain (GMT-7)