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: Specification rules around error logging


Hi all,

This question is coming out of discussions with one of our better-known DITA implementors.

In DITA 1.0 and 1.1 we had cases where the specification said that applications SHOULD or MUST generate an error message for certain conditions, or simply declared that implementations do so. In DITA 1.2 we largely switched over to the verbose "implementations may (but need not) recover by generating an error message". In DITA 1.3, these were largely simplified to "MAY recover".

The question I got was - why do we have these statements at all? We already state that these are error conditions, in which case applications can respond as appropriate for their context. This is highlighted by the fact that these are all MAY rules, giving applications permission to respond as they wish.

So the question for the TC is, do we need these? If we clearly and directly state that something is an error, is there any benefit to telling processors they MAY warn about the error? I think it's true that an application could generate an error message for everyâ error condition found in DITA source, but could also silently recover from every error. Both responses are valid. What's important for the spec is that we clearly identify the error conditions, so that implementations can find them and make that choice.

For what it's worth, we have this in about ten spots in the specification today -- a mix of "MAY recover by", "can recover by", and "might give an error message".

Thanks,
Robert


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