Re: [office-comment] CD01 -- 8.2.1 Referencing Table Cells

[Rick Jelliffe <rjelliffe@allette.com.au>]

Patrick Durusau wrote:
>
> My assumption has always been that conformance clauses are useful for 
> buyers to have a short-hand, "...do you conform to....(standard or 
> part of conformance clause)..." rather than having to specify 
> particular abilities. Perhaps the customer whats an entire set of 
> abilities.
>
> So the real question is whether or not we have mechanisms that allow 
> customers to specify particular sets of features, some, all, 
> particular ones and where should that be located?
The MIDI specification is an industry standard with tremendous success 
and universal implementation in the electronic music industry, from the 
largest studio equipment to moni ringtones.

It specifies various information that can be sent in realtime or put 
into a document (with timestamps)
   * music events (notes, clocks)
   * controller information (volume, vibrato, etc)
   * instrument selection

One of the most useful parts of the MIDI industry standard is the 
Implementation Note. All conforming implementations of MIDI (consumers 
or receivers) are supposed to generate information about the support for 
particular features.

A standard form is used, with checkboxes (O for yes, X for no!) and a 
remarks field. For an example, see
   http://www.korg.co.uk/downloads/kp3/support/KP3_MIDI_FX.pdf 

It may be that, apart from anything else, a kind of standard form guide 
like this, perhaps elaborating on the hint tables of features already in 
ODF, could be fairly readily made and added even to ODF 1.2.   It could 
be used to advertise feature support in products by vendors, to set 
desired features by procurers, to check compatibility points by 
sysadmins, and to guide users to the particular common set useful in a 
particular environment.

Because of ODF's structures, it may be that a simple (or nested) list 
based on all the ODF elements would provide a good amount of detail for 
solid comparisons and feature tracking.  Indeed, the form could even be 
autogenerated from the ODF TOC information (since the standard is 
organized to describe elements) or from the schemas. (This would have 
the advantage of not restricting particular application classes to 
certain feature sets, though the forms could be useful for documenting 
that subsequently too.)

This kind of form would be most useful if, for example, the ODF TC 
decided that ODF was facing a problem that people could never be sure 
what features had been implemented by each application under 
consideration: treating this not as an issue of technical deficiency but 
of information collation in a form useful for comparison.

Cheers
Rick Jelliffe