Re: [oiic-formation-discuss] Re: draft proposal 0.3 - Establishing the conformance landscape

["Dave Pawson" <dave.pawson@gmail.com>]

2008/7/29  <david_marston@us.ibm.com>:

> A well-written spec would have a conformance clause that defines which
> classes of product are intended to be subject to conformance testing. I
> didn't see such a clause in ODF 1.1, so I tried to discern the
> class-of-product intent from various parts of the document. See [1] for the
> OASIS view of conformance, but note that the dimensions of variability have
> been superseded by [2].

What the heck does that mean David :-)



 Based primarily on sections 1.5 and 1.7, I see
> references to the conformance of four classes of product:
> (A) Conforming reader or display application
> (B) Conforming producer of ODF, that is not an ODF editor
> (C) Conforming reader-writer, such as an ODF editor
> (D) Conforming ODF documents
> I think most of the discussion so far has been assuming conformance testing
> of (A) and a test regime would supply documents as input and examine how
> they are displayed by the app.

Not IMHO. As I've stated, many of the spec clauses are very much tied
to application behaviour, either directly or via the resultant XML
written to disk.
Many require something along the lines of :
Create some document (or fragment)
Carry out some manual action on an application
Save the file to disk
Examine the XML.

or

Load a file.
Carry out some manual action on an application
Check for change of state of the presented content.


 Testing of (D) would be more like validating
> the documents against a schema, which would also be an indirect test of (B).

I think there's quite a bit more than simple validation. A little closer
to the DSDL definition of validation. But generally yes, far simpler automated
checks.



> Perhaps (C) can be deferred, but it should be in scope for this TC.

It has to be for conformance, at least is the whole spec is to be tested.


>
> Also note that classes A-D above will have different stakeholders, as
> addressed in part 1f of the charter. I think we should strengthen the
> protection for class (D) stakeholders by explicit acknowledgement that some
> indirect beneficiaries hope to issue ODF documents that will be permannetly
> guaranteed to be readable by a conforming (A) reader.

Sorry. I've just read that twice and don't understand it. My attempt
at simplification.

Some users want to assure longevity for their files on disk? The archived
document? Is that it?




 Also, the
> vision-impaired should be acknowledged as appropriate for all the classes of
> product, so that conforming documents may someday be accessible to all.

If only the main TC could up the stakes and accept the accessibility
sub-committees
input as requirements. Sigh.

If I write a test spec, I shall include tests for each testable para
of that document.
(bias admitted)


>
> Yes, the ODF TC owns the definition of conformance for ODF. Let's hope that
> they do better in the future. I think it is reasonable for the Interop &
> Conformance TC to acknowledge the other TC's role as part of the charter.

I find that a little confusing. Especially as the main TC seem to have done
nothing about conformance as yet, not even beefing up statements to 'shall'
level as yet.


>
> In addition to class of product, Variability in Specifications [2]
> identifies other dimensions that may apply to ODF. The clearest one is
> probably discretionary items, since the spec gives a lot of leeway for
> specific items to be implemented or not. (But if they are implemented, they
> must conform.)

Example please? The myriad of 'may' statement? Is that the sort of thing you're
getting at?


>Extensibility is also present. I couldn't discern any use of
> levels, modules, or deprecation, but others may find something.

I don't understand that David.




>
> Profiles are a very interesting dimension of variability for ODF. Appendix D
> of 1.1 hints at some possible profiles, one for each column in the table.

 I could see uses (possibly not unlike your classes above).
Equally I couldn't see a clear use case within the current spec, hence
I've put profiles as an area of investigation, leaving it to the TC to
consider how to use them. I note that the appendix doesn't appear
to fully cover your classes above. Do you know of any class D applications?
I.e. using the schema without being an interactive application? Is simple
validity sufficient? Probably not with such a loose schema.


> The draft charter for this TC identifies other potential profiles under 1c,
> bullets 4 and 5.

No it doesn't. The IBM/Rob document does. The work collected from
members of this list says consider them.

This is not necessarily a conflict with the ODF TC's
> ownership of the specification of conformance; a spec can permit others to
> develop profiles. I urge all who would like to reword the charter to read up
> on profiles.

If you can provide a workable definition of profiles, wholly relevant to ODF
and usable in the IIC TC,  then I'd love to include it. I find them tempting
but just a little out of reach.



regards




-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk