OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  Re: [office] Moving forward on Conformance

    Posted 02-03-2009 16:30 
    Hi Rob,

thank you for this summary. I think it very well describes the situation.

What I would like to add here is what you said in another mail, that is, 
that we must also consider that some more work regarding conformance is 
done in the OIC TC.

So here are my preferences.

On 02/03/09 17:06, robert_weir@us.ibm.com wrote:
> 1) For products, I'd like to see us follow C) and define conformance for 
> ODF Documents, Producers, Consumers and Processors.  B) would also be 
> acceptable.

My preference is B). The simple reason is that is appears to be 
difficult to define requirements for processors without specifying what 
their purpose is.

I actually could imagine that it may be much easier to define 
conformance for processors in the OIC TC, where we may define different 
classes of processors.

> 
> 2) For conformance classes, My preference is for C, but B would also be 
> acceptable.  Of the dual-class choices, E is the least offensive.

C would be my preference, too, but B is also acceptable.

> 
> 3) And for the last question, this will depend on what agreement we can 
> arrive to on the other two questions, but I generally want to avoid a 
> proliferation of conformance classes, with applications as well as 
> documents.

I agree to this, too.

Best regards

Michael

-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


  • 2.  Re: [office] Moving forward on Conformance

    Posted 02-03-2009 19:30 
    Thanks for the response.  I hope others could weigh in on how their 
preferences fit into this framework.  I know Dennis sometimes likes to 
find interesting possibilities between my choices, so if he or anyone else 
prefers a B-prime or something like that, please go ahead and define that 
preference.  But I think the underlying questions are the key ones:  What 
products? What conformance classes? What classes apply to what products?

-Rob

> 
> Hi Rob,
> 
> thank you for this summary. I think it very well describes the 
situation.
> 
> What I would like to add here is what you said in another mail, that is, 

> that we must also consider that some more work regarding conformance is 
> done in the OIC TC.
> 
> So here are my preferences.
> 
> On 02/03/09 17:06, robert_weir@us.ibm.com wrote:
> > 1) For products, I'd like to see us follow C) and define conformance 
for 
> > ODF Documents, Producers, Consumers and Processors.  B) would also be 
> > acceptable.
> 
> My preference is B). The simple reason is that is appears to be 
> difficult to define requirements for processors without specifying what 
> their purpose is.
> 
> I actually could imagine that it may be much easier to define 
> conformance for processors in the OIC TC, where we may define different 
> classes of processors.
> 
> > 
> > 2) For conformance classes, My preference is for C, but B would also 
be 
> > acceptable.  Of the dual-class choices, E is the least offensive.
> 
> C would be my preference, too, but B is also acceptable.
> 
> > 
> > 3) And for the last question, this will depend on what agreement we 
can 
> > arrive to on the other two questions, but I generally want to avoid a 
> > proliferation of conformance classes, with applications as well as 
> > documents.
> 
> I agree to this, too.
> 
> Best regards
> 
> Michael
> 
> -- 
> Michael Brauer, Technical Architect Software Engineering
> StarOffice/OpenOffice.org
> Sun Microsystems GmbH             Nagelsweg 55
> D-20097 Hamburg, Germany          michael.brauer@sun.com
> http://sun.com/staroffice         +49 40 23646 500
> http://blogs.sun.com/GullFOSS
> 
> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
>       D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
> Vorsitzender des Aufsichtsrates: Martin Haering


  • 3.  RE: [office] Moving forward on Conformance - OIC Role

    Posted 02-09-2009 04:23 
    I saw these mentions of what OIC might do with regard to conformance and I
wanted to clarify my still-learning understanding of that.  

 1. The OIC cannot do anything about the conformance levels and the
normative statements of the ODF specification.  It also can't (well,
shouldn't) do anything that results in contradiction of the conformance
levels and normative statements of the ODF specification.

 2. In determining how to assess conformance, the OIC may discover areas
where the ODF specification is underspecified or inconsistent and report
those finding to the ODF TC.  There may also be discoveries of
misunderstandings and disagreements about the requirements among
implementers, and that can be reported to the ODF TC as well.  (My guess,
and only a guess, is that none of this is likely to coincide with current
ODF 1.2 development, based on the desired movement of ODF 1.2 toward OASIS
Standard and the early stage that OIC effort is in.) 

 3. Where the OIC may be valuable is in the area of optional normative
statements, where there are MAY, NEED NOT, SHOULD, SHOULD NOT.  Also, there
may be something to do in regard to other optionality and discretionary
matters (maximum table dimensions, for example).  And, it may be valuable to
notice what implementations are doing, if anything, around places where the
ODF specification is silent or underspecified or apparently has left matters
to be determined by implementations.  
    3.1 In this case (with great caution where there is no explicit guidance
in the ODF Standard), the OIC might promulgate a profile that defines a
level of document, consumer, and producer for successful interoperable
usage.  Such a profile would presumably limit some optionality in order to
achieve the interoperability and might specify more about how interpretation
of unsupported provisions are to be handled under the profile.  
    3.2 I don't know that ODF TC concurrence would be required in this case.
Perhaps such a profile could move to OASIS Standard in its own right, even
though it is based on and completely dependent on a specific ODF standard.  
    3.3 Perhaps something that would be valuable for the establishment of a
profile is provision in the ODF specification of an agreed way to amend MIME
types and office:version values, or other metadata, to indicate the
additional protocol agreement that a document conforms to and should be
employed in its processing.
    3.4 I am making this all up.  The OIC has not looked at this, although I
am going to forward this note to that list also.

 4. I'm not sure about extensions.  I think that is not the business of the
OIC except to perhaps recognize the possible existence of any extensions in
common use among multiple implementations.  This strikes me as not something
for OIC to have its attention on in the near term.  

 - Dennis


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content