OASIS Open Document Format for Office Applications (OpenDocument) TC

This is a draft of some language I'll be proposing to define additional 
conformance targets for the main document types: text, spreadsheet, 
presentation, chart, drawing and image.  The goal to to set some minimum 
requirements in terms of mimetypes and file names, as well as set a 
reasonable upper bounds for expected contents.  For example, it doesn't 
make sense for an ODF spreadsheet to contain animated page transitions. So 
let's say so.

Of course, any vendor is free to add "animated page transitions" to their 
spreadsheet if they wish.  In fact, they could still claim it as a 
conforming ODF Document.  However, it would not be a conforming 
OpenDocument Spreadsheet Document.  So this proposal is 100% backwards 
compatible with what we had in ODF 1.0 and ODF 1.1. 

These specialized document targets specify constraints on static factors 
like namespaces, mime types and syntax.  It will be straightforward to add 
Producer and Consumer targets corresponding to each of these to 
constraints on runtime behavior.   The Producer/Consumer targets will 
likely invoke the requirement to process and be consistent with the 
semantics defined for the elements and attributes which are allowed in 
that document type.  I'll work on writing up these Producer/Consumer 
targets next.

-Rob


------------------------------------------------------------------------
1.4.2.3 Conforming OpenDocument Text Document

(D3) A conforming OpenDocument Text Document shall meet all requirements 
of a Conforming OpenDocument Document, as well as the following additional 
requirements:

(D3.1) The 

On Sun, 2009-03-15 at 17:49 -0400, robert_weir@us.ibm.com wrote:
> (D4.3) If the document  is an OpenDocument package and it is stored as
> a 
> file, then the name of the file shall have the extension ".ods".

What is the point of this exercise? The document is what happens to be
stored in the file. Saying that a user can turn a user can turn a
Conforming OpenDocument Spreadsheet Document into a non-conforming one
by simply changing the name of the file is just ridiculous! The mimetype
can be deduced from the content of the file so why does one have to
specify that the name of the file (or even part of the name).

Andreas
-- 
Andreas J. Guelzow
Concordia University College of Alberta

Andreas J Guelzow 

On Sun, 2009-03-15 at 22:39 -0400, robert_weir@us.ibm.com wrote:
> To accomplish there we need to either ensure that producers write the data 
> consistently, or that consumers use a more complicated heuristic to 
> determine document type.  I'm inclined to believe that this will work best 
> if we require both.

I find it greatly disturbing that the standard would try to force an
application to show certain latin letters in a file name just to have
that file to be considered a conformant document. 

Perhaps if you weren't used to writing in the latin alphabet it would be
more obvious that having such cryptic (and in the user's language likely
meaningless) letter combinations attached to a file name.

Andreas
-- 
Andreas J. Guelzow
Concordia University College of Alberta

Andreas J Guelzow 

On Mon, 2009-03-16 at 00:10 -0400, robert_weir@us.ibm.com wrote:
> Andreas J Guelzow 

I share Andreas's concern, although I certainly support the idea of having
specific document-type determination, and if it takes a conformance target
to do that (because of upward compatibility issues, etc.), I can live with
that too.

I do think we need to be careful about file extensions.

1. For ODF 1.2, I think we should consider requiring strict associations of
MIME types (and the mimetype Zip item value and the office:mimetype
attribute value) with document types in the sense that the content of the

   1. I notice that the template cases are not included.  Do you want to
handle those?  Would they be instances of the same Templates are a valuable
tool in support of interoperability arrangements.  I wonder if they can
simply be included under the corresponding conforming document type?

   2. You appear to have set a new ceiling, but there is no new floor within
those constraints, other than the existing constraints on conformant
documents.  That makes sense, although I think we need to deal with other
prospective exclusions (binary objects, applets?)  When characterizing
consumer, producer, and processor targets, shall we have preservation
requirements on elements that a producer does not support/interpret or must
a processor be capable of processing and producing all of its target class,
rather than simply producing documents confined to the target?

   3. I don't think a requirement to support all of OpenFormula will fly.
What will be done about the different conformance levels for OpenFormula?

   4. Do we need some way for a producer to assert the conformance target in
the document so that a target-constraining consumer can confirm/reject the
document accordingly?

   5. I continue to think we should consider that the document type
determination be a normative part of the specification, with the target
having the additional requirements for what shall and shall not be
supported.  (I think of type determination as more like schema than
interpretation, its just that we have attribute and package item values that
determine the applicable schema.)

   6. I also think this is a big deal.  It looks like the details should be
hammered out in wiki drafts until we feel we have surrounded the situation
and understand the implications on normative language throughout the
specification, what this may raise as an issue for implementers (and
adopters), etc.  I fear the law of unintended consequences biting us here.

 - Dennis



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Sunday, March 15, 2009 14:49
To: office@lists.oasis-open.org
Subject: [office] Conforming OpenDocument Text Document, etc.

[ ... ]

These specialized document targets specify constraints on static factors 
like namespaces, mime types and syntax.  It will be straightforward to add 
Producer and Consumer targets corresponding to each of these to 
constraints on runtime behavior.   The Producer/Consumer targets will 
likely invoke the requirement to process and be consistent with the 
semantics defined for the elements and attributes which are allowed in 
that document type.  I'll work on writing up these Producer/Consumer 
targets next.

-Rob


------------------------------------------------------------------------
1.4.2.3 Conforming OpenDocument Text Document

[ ... ]

(D3.1) The