I apologize for not reviewing this earlier. But since I woke up this
morning at 4am, due to jetlag, I find myself free of meetings for a few
hours, so I will make some comments now. Overall I like the progress over
ODF 1.0/1.1. This is an important part of the standard, and will get a
lot of attention during the review in OASIS, as well as in JTC1 when we
submit ODF 1.2 for PAS approval. So I'm hoping we can consider my late
comments and perhaps make another iteration over this section.
I reviewed the "sixth iteration" dated 11/11/2008.
I think it would be good if we started the conformance section with a
clear statement of what we will be defining. Something like, "The
OpenDocument Format standard defines conformance for documents, generators
and processors, with two conformance classes called loose and strict."
We'll need something like that for the Scope statement as well. Probably
want to synch up on the language.
I'm a little confused by the term "processor", since it is defined,
somewhat circularly, as "a program that can parse and process OpenDocument
document". What is "to process"? What is intended, beyond parsing?
To my thinking, we have three kinds of applications:
1) generators (or writers or producers)
2) parsers (or readers or consumers)
3) processors (that both read and write)
I think we may be failing to acknowledge that 3rd kind of program, the
ones that both read and write. As we know, this brings in additional
questions related to round-tripping, and that this is a thorny issue. But
it is a legitimate concern, and we should see if there is some language
the TC can agree to for it, especially considering that most ODF
applications fit into that category, and in practice interoperability
would be enhanced by any firmer guidance ODF 1.2 can provide in this area.
Here are some specific comments:
Document processing --
"Documents that loosely conform to the OpenDocument specification..."
We introduce here the term "loosely conform" but we don't clearly indicate
what our conformance classes are. For example, do we want "loose
conformance" and "strict conformance"? or plain "conformance"? Is there
a better word than "loose"? It carries a negative connotation in my ears.
Also, do we need loose conformance at all? Why not just have a single
conformance class and anything beyond that is not conformant? Then, if
there occurs a commonly-used set of extensions to ODF, in a foreign
namespace, then we can either included that in ODF-Next, or (more simply)
define a profile for the extensions.
"Foreign elements and attributes shall not be part of a namespace that is
defined within this specification."
"part of a namespace" is rather loose. The term used by the Namespaces in
XML Recommendation is "associate". So I suggest, "Foreign elements and
attributes shall not be associated with a namespace that is defined within
this specification."
"If a foreign element has a or ancestor element and is a child elements
of an element which may include..." Typo. Should be "child element"
(singular). Or do we really mean "descendant element"?
"For foreign elements that occur at other locations, conforming processors
should not process the element's content, but may only preserve its
content"
We have not defined "process". Does it include "preserve its content"?
Also, why not make preservation of content of foreign elements be a
"should"? Is there any reason why we would not make that recommendation?
In any case this "Document processing" section seems misplaced. I wonder
if it fits better if put in the Generator or Processor conformance
section, since it is defining conformance.
So overall, I find this document processing area thorny and troublesome. I
would not be disappointed if it were entirely removed from the standard,
or moved to an informative annex on "How to extend ODF". There is little
value to implementors or users in having a conformance class for documents
that are extended in nearly-arbitrary ways. Nothing written here really
allows such extended documents to interoperate. On the one hand, I don't
believe that there is anything intrinsically evil with extensions, but I
don't think that we need to favor them with the label "loose conformance".
Do we know what implementations today use foreign elements and attributes
according to this section? Is the usage widespread?
"Conforming OpenDocument Documents" -- this is defined currently as a
condition, if/then. But I think it should be stated as a requirement: "A
conforming OpenDocument document shall adhere to the specification
described in this document...". Similarly, "An OpenDocument document
which is also an OpenDocument Package shall...".
Generally, we should use "conform" rather than "adhere" whenever possible.
Do we want to require a specific XML character encoding?
2.1.3 -- "f the XML root is.... then it shall be valid with respect to
the strict schema defined by this specification." What is "it"? "XML
root" doesn't make sense? "Sub document" maybe? A similar question in
2.1.4.
"Conforming OpenDocument Generators" has the first conformance requirement
stated as "It shall not create any non-conforming OpenDocument document
of any kind." But this, stated as a negative, is untestable. How can an
implementation prove that it is incapable of producing a non-conforming
ODF document? What, for example, if the power goes out when in the middle
of saving a document? Would that render the entire application
non-conforming?
I'd state this requirement more simply (and more testable) as "It shall
produce documents which conform to this standard".
We might factor out the common requirements between normal and loose
conformance rather than repeating material. For example, we are currently
stating the documentation requirement twice.
My preference would be to make the document requirement be a "shall"
rather than a "should". I think we're giving implementors a lot of rope
to play with by allowing a loose conformance class, a significant ability
to extend the standard in incompatible and proprietary way. As stated
before, I'd be happy if this ability were removed altogether. But if we
do allow it the label of "conforming" than I think we should require
documentation of the extensions, not merely recommend it.
"Conforming OpenDocument Processors" -- "process" is not defined.
"It be able to parse and process OpenDocument documents of one or more of
the defined document types (defined by their MIME types) any of which are
represented in packages." I don't think we need to mention MIME types
here. We can just say "able to parse and process OpenDocument packages of
one or more of the document types defined by this standard". Better even
if we can give a section reference.
Why is the single XML version a "may" rather than at least a "should"? It
is odd to have the single file version be present (and not deprecated) if
we do not feel it warrants more than a "may" for support.
Regards,
-Rob