< Return to Ballot details

Vote Details

Ballot: "ODF 1.1 Interop Profile CD01-rev4" as CD02 and Public Review
Company:
Individual
Vote:
Abstain
Comment:
After observing the development of this document and reviewing the current draft, my discomfort with the approach has not diminished.

I am abstaining. I can agree to this becoming a Committee Draft. I am very uneasy about submitting this to Public Review as a prospect for taking to Committee Specification and beyond.

My concern with the approach is that we are over-reaching our charter by specifying extremely broad conformance targets along with strict conformance clauses that might better serve as guidance for producers rather than conditions on conformance. I think the all or nothing support for all interoperability provisions applicable to a single conformance target are not helpful and too heavy-handed. I also don't think we are served by defining a Conformant Interoperable ODF Document in this manner.

- - - - - - - - - - - - - -

The following comments illustrate some of my concerns. They are based on a cursory examination and are not comprehensive. Resolving these comments is not likely to alleviate my over-riding concern.

A. Normative References (1.2)

[ODF 1.2] is inappropriately included as a normative reference, and the reference is to a superseded document. Any references to ODF 1.2 drafts should be non-normative, even if used as the rationale for a interoperability provision in this profile. The specific Committee Draft(s) and Part(s) should also be identified.

[OFF] is seriously inappropriate as a normative reference. It identifies a committee working-draft document that has not even been designated a Committee Draft.
I don't believe that it is desirable to introduce a different conforming document other than the conforming document provided in the ODF 1.1 specification.


B. Terminology (1.1) and Conformance General Clauses (3)

The terminology section to name conformance targets and then uses shorthand identifiers for them. It is better to identify ODF 1.1 Producers, Consumers, Documents, and Implementations as special terms and identify the targets in section 3. Using codes should be avoided. They are too noisy and a mess for translators.

I suggest Interoperable Producer, Interoperable Consumer, etc., are preferable as names for these conformance targets, always using proper (capitalized) names. They could be listed in a terminology section too, but referencing the definitions in section 3.

Finally, being "capable of" is not great as a conformance qualification.


C. Other Concerns (Miscellaneous)

Some conformance clauses are contradictory. For example, (S8.1.3-1) allows the syntax of formulas to be established by use of a namespace whereas (S8.1.3-2) dictates a specific syntactical requirement.

For (S3.1.1-2), there is no target and it appears that the only meaningful requirement is (S3.1.1-3) stated as producing exactly one and with any tightening of the definition with respect to RFC 2616 that is necessary.

It seems that (S3.1.6-1) is a requirement that an interoperable producer provide the element and nothing more. Note that no conformance target is specified. I just created a spreadsheet where I removed all author-identifying metadata because I don't want modified versions to be identified as from me in any way. Could I do that with a conforming interoperable producer?

Why have both (S3.1.17-2) and (S3.1.17-3)? There must be a better way to say (S3.1.17-4) and why have days at all? If this is meant to be cumulative, we need to say something more about that too. Days don't strike me as the same as accumulated wall-clock time. If a consumer encounters acceptable values (including no values) that are outside what interoperable producers produce, what is an implementation expected to do on producing an update of the document?

(S8.1.3-1) This should be a Conformant Interoperable Producer conformance clause. I think this is all you need for 8.1.3, except I would reword it as follows:
"table:formula attribute values shall begin with a namespace prefix and a following ":" character. The namespace prefix shall be Namespace Valid [xml-names] and the namespace shall be one for which the syntax and semantics of the formula following the prefixed ":" is specified."

I believe that everything else here about 8.1.3 is accomplished by the above.

(S8.1.3.4) fails to deal with the case where other cells may have their values changed and the formula should be recalculated, but there is no way to recalculate or even know that recalculation is required. If, in addition, other formulas are introduced for different cells, how are these to be reconciled with the not-understood ones?

(S8.1.3.5) strikes me as a bad idea. I would remove it.

The additional "Conformance once [OFF] is approved" clauses are meaningless. How can we even have this when we don't know what will be entailed. Also, we are retroactively imposing this condition on ODF 1.1 and that seems even more questionable.

(S17.4-1) should be a producer requirement, not a document requirement.

- Dennis