OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office] Some ballot request - ODF 1.2 part 1 conformance clause

All of these comments are about the fourth iteration.  It took me some work
to be comfortable enough with the proposal and the relevant parts of ODF 1.1
and ODF 1.2 (draft) to comment.  I apologize for providing it later than
Michael requested.  I have more comments than I expected when I started.

 - Dennis

DOCUMENT PROCESSING section comments

I think the "If it isn't broken, don't fix it" principle applies here.  I
don't see why it is worth a breaking change to deprecate
office:process-content and change the default for processing of foreign
elements to be one based on context.  The current rule may be awkward, but
it is specific enough and there is a way to specify any different result.

There are other subtle differences, some that show up with differences in
what is conformant.  I am concerned that these are unintended consequences
and that we will prevent ODF 1.1-compliant applications from becoming ODF
1.2-compliant using just the ODF 1.1 elements and attributes (and foreign
elements and attributes).  

I also notice that the statement about preserving processing instructions is

If ability to validate documents using NVDL is a big concern, you might
deprecate office:process-content="true" and define
office:process-document="false" as the only non-defaulted case.  That
doesn't feel like an improvement, though.   

CONFORMANCE section comments

D1.1.2 I don't understand how there can be conforming documents with no
<office:body> element.  What could the MIME type possibly be?  So I would
think that the document package would have to contain a content.xml file.
The <office:document> schema requires <office:body> and it would seem to be
naturally required for the package of a complete document.

Because of rules like 17.5, I also don't see how there can be a top-level
package for a complete document that doesn't have all the needed major
subfiles, and that would include content.xml at least.  External parts that
are linked-into the structure for the complete document would not appear to
have to be Conformant ODF documents themselves.

[I assume I am missing something.  I can't tell from 1.1 or from the schema
for 1.2 why this conformance statement is so loose for non-loose documents.]

D1.2 The table that associates subfile names and root elements seems to have
disappeared from the current ODF 1.2 draft.  I would name the elements that
are the roots of the four subdocuments, for cross-reference to the sections
that define them and name the subfile name that is used.

[I don't understand the reference to <math:math> in this context.]

D1.3 I don't think it is table 4 (or 5 in draft 7-10) that defines the
element.  The element is currently defined in section 2.2.2.  Can't the
element be named in D1.3, so cross-reference works?  [Also, there needs to
be some recognition that <office:document> and <math:math> can appear as
other than root elements also although that might not matter in the
conformance clauses].

[Does there need to be some statement about subfiles and external files that
are referenced from the key ones or is this simply covered.  I would think
<math:math> is always caught by either reference or containment under the
structure of one of the specific document-type root elements (i.e., under
some <office:body> element).]

D1.4 Replace "(1.2)" with "(D1.2)" and "(1.3)" with "(D1.3)".  The XML 1.0
specification, the XML Namespaces specification, and the XML ID
specification (whatever their proper names are) need to have references to
their citations in the normative references of the specification.

D2.1 is confusing.  I think it should be broken into two parts.  In once
case we talk about the (unnamed) root elements in subfiles having particular
names.  In the other case there is discussion of a particular <math:math>
root element in an (unnamed) subfile.   It seeems difficult to make sense of
these when combined in the same sentence.  [I'm also curious whether there
are other XML root elements that might arise under similar conditions to
those for <math:math>.]

G1.2 I suggest that 

", but it *shall* have a mode of operation where all OpenDocument documents
that are created are Conforming OpenDocument documents" 

be replaced by 

", and it *should* offer means to require that documents be created as
Conforming OpenDocument documents instead of Loosely-Conforming OpenDocument

[I am concerned that we are being too specific about how such a provision
might be enacted in the implementation of a conforming generator.  It is
also a breaking change against ODF 1.1-conformant applications.  In the
absence of a special class of Loosely Conforming Generators, I'm concerned
about this provision preventing generators in an application setting where
the generation of Loosely Conforming OpenDocument documents is essential to
the working of the application.  If we are going to allow so much looseness
in processing of even conforming documents (P1), it seems odd to be so fussy
about generators, especially when these conditions to not apply to
generators of earlier versions of ODF documents.]

P1.1 It seems to me safer to say
     "It shall 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 you want to require a single processor to be able to process
all document types.]

P1.2 Here I would say that 
     "It may be able to parse and read OpenDocument documents of any type,
whether represented in packages or in single XML documents."

[Are you intending to deprecate the single XML document case?  Why prevent
conforming processors that only process single XML documents for an ODF
application, if that hasn't been prevented before?  Why reduce the prospect
of interchange for such documents?]

P1.3 "... but it may not interpret ..."

     should be

     "... but it *need not* interpret ..."

P1.4 "... but it may not interpret the semantics of elements, ..."

     should be

     "... but it *need not* interpret the semantics of all elements, ..."
(notice "all elements")

[I am curious to know what is gained by saying *should* instead of *shall*
here, since it is a modest requirement to parse loosely conforming
documents.  Handling loosely-conforming documents does not involve doing
much with foreign elements and the processor already has permission to treat
conforming document elements, attributes, and attribute values as if they
are effectively foreign elements.]

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Wednesday, October 29, 2008 09:53
To: OpenDocument TC
Subject: [office] Some ballot request

[ ... ]

As already mentioned in the last TC call, I further would like to ask 
for a ballot on the conformance clause proposal:


Best regards


[ ... ]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]