OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Hard to know conformance requirements (ODF pt 1, public review 1)

Dear all,

The spec describes conformance in respect of three types of thing:

- documents

- consumers

- producers

Yet throughout the text sometimes mention is made of other (undefined) types of thing, for example:

- "office applications"

- "editing applications"

- "implementations"

Very often, no mention is made of what type of conformance is being targeted; yet some kind of specific behaviour is mentioned. For example 9.3.4:

The <table:highlighted-range> element specifies a cell range that is highlighted in the UI either because of detective operations defined by a <table:operation> element or because it contains an error or invalid data.

This normative language makes mention of a highlighted cell range. What is it doing the highlighting? Is something (an "office application"?) that doesn't highlight the cell range (in "the UI") non-conformant?

Another example 9.1.7, 

If a table does not fit on a single page, table rows that are included in a <table:table-header-rows> element are automatically repeated on every page.

Must ODF implementations have some concept of a "page"? And even if they do, can they not innovate in the way they are displayed (on a scrolling canvas rather than in-page for certain views, maybe?) or does conformant behaviour require in-page rendering of the repeated rows?

More generally (and in these examples), the text suffers from a lack of clear conformance language. Where we might expect "shall" or "should" instead we get much use of the present tense in ODF.


- "If a parent style is not specified, the default style which has the same family as the current style is used." (19.508) (again, used by whom?)

- "If this attribute is not present, the display name equals the style name." (19.474) (a given fact, or something that must be done?)

- "The element displays the actual row number from ac[sic] database and not the row number of a current selection that is used as an attribute value in the <text:database-row-select> element." (7.6.6) (lots wrong with this sentence)

When "is" is used, it is not clear whether this is mandatory behaviour or recommended behaviour - and it is not possible to understand always whether something needs to be done or some existing state is being described.


- Consider whether some additional conformance targets (e.g. office applications) exist in the text but have not been defined as conformance targets; if not, re-cast the text to make clear when provisions are made, what classes of conformance target are in scope for those provisions; remove mentions of targets that are not formally defined as conformance targets.

- If text is purely specific to office applications and not generally to "consumers" relegate that text to notes or move it out of the specification (to an office developer handbook, maybe); do not leave hints about office development practices as normative text - this is meant to be a document format specification, not an office behaviour specification, after all! (and granted, specifying application behaviour may have a place - but doing it comprehensively would be a major project).

- Make an editorial pass of the text checking for provisions made using clauses build around present tense verbs; recast them to use ISO control language ("shall", "should", etc.) as appropriate.

- Alex.

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 

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