Thanks for the response. No need to apologize for the delay. I am
certainly late in responding to your initial proposal, and I appreciate
being able to discuss this further.
-Rob
Michael.Brauer@Sun.COM wrote on 11/21/2008 07:54:43 AM:
>
> Hi Rob,
>
> thank you very much for your feedback. It took me unfortunately a little
> bit longer to respond than I hoped it would.
>
> On 11/17/08 14:14, robert_weir@us.ibm.com wrote:
> > 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.
>
> Yes, this sounds like a good idea.
>
> >
> > 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)
>
> This is what is meant by the term "processor".
> What about using the term interpreter rather than parser?
> SVG uses this term:
>
> http://www.w3.org/TR/SVG11/conform.html#ConformingSVGInterpreters
>
> The conformance clauses for SVG interpreters state:
>
> "A Conforming SVG Interpreter must parse any SVG document correctly. It
> is not required to interpret the semantics of all features correctly."
>
> So, this is actually close to what is called an "ODF processor" in the
> current proposal.
>
We can call it anything of these things (processor/interpreter/parser) so
long as we explicitly define what that term means. The level of
description from the SVG Recommendation is fine. My preference would be a
term that denotes consumption of ODF, similar to how generator implies
production of ODF. In fact, Producer/Consumer is a natural pair, as is
Reader/Writer, or Generator/Parser. But Generator/Processor does not (to
my ear) have that kind of equivalence.
What do others think on this?
>
> > 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.
>
> I agree. But the requirements for applications that read and write
> documents heavily depend on the purpose of the application itself. We
> also have to consider that between a read and a write some or all of the
> information that is contained in the document changes, but that we don't
> know which information and why it is changed. That makes it very
> difficult to find requirements that are testable.
>
This is true. But the question is whether there is a common subset of
typical uses that is worth giving a label to?
For example, if we take a Processor as something that reads and writes
ODF, then some obvious requirements might be:
1) It is also a conformant ODF Generator/Producer/Writer
2) It is also a conformant ODF Parser/Reader/Consumer
and maybe
3) It is capable of an identity transform, meaning it is capable take an
input document and write out an "equivalent" document (however we define
that).
The idea is that although it may mainly operate by changing the input
document, it should have a mode where it is capable of not changing the
input document. Then we can put shall or should around preserving
metadata and foreign elements/attributes.
The tricky part is around what "equivalent" means. Certainly changing
namespace prefixes, ordering of attributes, style names, etc., should be
flexible. We get some of this via reference to the W3C's Canonical XML
standard, if we want. But we really need a definition of Canonical ODF to
define logical equivalence of ODF documents.
So I think I answered my own question here. There is not much interesting
we can say about a read/write processor at this point.
> I could actually imagine that this kind of conformance could be much
> better addressed by the OIC TC, where we may bind the requirements to
> profiles.
>
> >
> > 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.
>
> You are right that we use the term "loosely conform" before we define
> it. This could be solved by moving the document processing section
> behind the conformance clauses.
>
> The two proposed conformance classes are "conformance" and "loose
> conformance", but I'm open for other suggestion how to name them. I have
> chosen the term "conformance" to emphasize that this is actually the
> type of conformance that applications should aim to achieve. We may also
> call the classes "strict conformance" and "loose conformance". I'm not
> in favor of calling them "strict conformance" and "conformance", because
> this may sound like that "conformance" is what applications should
> achieve, while "strict conforamance" contains some optional requirements
> only that may or may not be achieved. That's not what was intended by
> having two conformance classes.
The thing I don't like about "loose" conformance is that the additional
allowed data -- the foreign elements and attributes -- have no meaning
whatsoever. All we say about them really is that the document must be
valid after they are removed. So this isn't "loose" versus "strict" like
HTML Transitional versus HTML Strict, where the Transition form has
defined functionality beyond Strict.
> >
> > 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.
>
> I have thought about this myself for a long time. One reason why I have
> added the "loose" conformance class was that we allowed foreign elements
> in ODF 1.0 and 1.1. The other reason was that vendors may have
> the issue that they have to store some information in a file
> immediately, for instance because a customer requested this, and cannot
> wait for the next ODF version. The assumption here of cause would be
> that they propose the extension to the ODF TC, so that it would be used
> only temporarily. In so far, there may be indeed better solutions than a
> separate conformance class. I will think about this.
>
We can't stop vendors from adding extensions like this. But we are not
required to add a conformance class for them either. We could just say
that such documents are not conformant to ODF 1.2.
It is always a trade-off and there is no clear "right answer", but at the
extremes we can have:
A) A very loose definition of conformance that allows many ODF vendors to
claim conformance because the mandatory requirements are very few.
or
B) A tight definition of conformance that may result in fewer conformant
ODF applications, but the ones that are conformant are more likely to be
interoperable.
I think we want to move in the direction of B in ODF 1.2. We may not be
able to move there all at once or suddenly. But one step is to avoid
introducing a conformance class for something that is inherently
non-portable and not interoperable.
> What seems to be essential here is that we define rules how foreign
> element and attributes are processed. This means, we may remove the
> loose conformance class, but we must not remove the processing rules for
> foreign elements and attributes.
>
Yes, this could be preserved, even with a single conformance class.
> In any case, I think we should remove the "loosely conformant
> OpenDocument generator" again. An applications that calls itself
> conformant shall be able to store conforming file.
>
>
> >
> > "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."
>
> Yes, that's a good suggestion.
>
> >
> > "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"?
>
> It is a typo. And "child element" is correct. The case this addresses
is:
>
>
>
> In this case, "My new replacement" should not be displayed because it
> belongs to a text frame (that is displayed outside the text flow) rather
> than to the text of the paragraph.
>
> With the current wording, it would not be displayed, because
>