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

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi Dennis,

thank you very much for your feedback. It is very helpful.

On 10/31/08 07:43, Dennis E. Hamilton wrote:
> 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.

The reason for this change exactly was the ability to use NVDL, together
with the fact that we have in ODF 1.2 a powerful metadata feature that
will make the use of foreign elements obsolete in many cases.

So, I simply think it would be a pity if we on the one hand switch to
NVDL which allows us to validate document much better than before, but
to have on the other hand a feature in the schema itself where we can
describe the validation rules only as prose.

> 
> 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

I tried to explain all changes that I have made with the iterations, but
maybe I have overseen one. So, what changes are it that you think may be
unintended?

> elements and attributes).  
> 
> I also notice that the statement about preserving processing instructions is
> removed.

Yes, that is correct. I have removed this in the 2nd iteration for the
same reason as the other requirements regarding preserving elements and
attributes. The problem is that a document gets loaded, intentionally
changed, and is saved again, and it is not possible to figure out
whether a processing instruction still should be in the document or
not. One could take the processing instruction for the cursor position
that ODF defines as an example. The document is loaded, the reader of
the document moves the cursor, and saves the document again. The cursor
position processing instruction then definitively should not be preserved.

The "should" language we had of cause allows to remove the processing
instruction if there are good reasons for this, but if there are good
reasons or not cannot be tested, and the requirement itself therefore is
not really testable.
> 
> 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.

Document templates which only contain style information don't require a
<office:body>, and therefore also no content.xml.

I'm not sure if there are use cases for having documents that contain
neither a content.xml nor a styles.xml. So, what about stating that at
least one of the two streams have to be present?

> 
> 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.]

See above. It may be too loose. At least a content.xml or a styles.xml
should be present.
> 
> 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.

Oh. I didn't notice that. The table of cause has to be re-introduced. Or
we state the relation between stream names in the conformance clauses
itself. I need to check what does work better with the current
structure, but, yes, something must be added.

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

ODF formula documents have plain MathML within their content.xml.

> 
> 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

Yes, that's a good idea.
> 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].

Well, I have never thought about a plain XML file that contains a math
documents. This would just be a MathML document.

> 
> [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).]

I'm not sure if I do understand this comment.
> 
> D1.4 Replace "(1.2)" with "(D1.2)" and "(1.3)" with "(D1.3)".  The XML 1.0

Yes, good point.
> 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.

Yes, also a good point. For simplicity I would like to do that when the
proposal gets integrated into 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

Yes, the sentence is too long.
> are other XML root elements that might arise under similar conditions to
> those for <math:math>.]

There are no other root elements.
> 
> 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
> documents."
> 
> [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.]

What about adding the notion of a loosely conformant generator?
> 
> 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."

Yes, that is a very good suggestion.
> 
> [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."

We have already stated that packages must be understood. So why should
we repeat this with a weaker "may"?

> 
> [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?]

Well, in the past we did not really state whether an application has to
support packages, plain XML files, or both. But all application I'm 
aware of implement packages. So, yes, maybe we should deprecate the flat 
format.

Anyway, if we would state that an application has to support either 
packages, or plain XML files, then we would have to introduce different 
conformance terms for these, because otherwise they may not be 
interoperable.


> 
> P1.3 "... but it may not interpret ..."
> 
>      should be
> 
>      "... but it *need not* interpret ..."

This sounds indeed better, but I have  to check whether this is in the 
ISO keywords.
> 
> 
> 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")

See above.
> 
> [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.]

That's an interesting question. With the office:process-content 
attribute it is not trivial to parse loosely conforming documents, but 
if we deprecate this, then this should be much easier.

Again, thanks for your feedback. I will update my proposal.

Best regards

Michael
> 
> -----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:
> 
> http://lists.oasis-open.org/archives/office/200810/msg00105.html
> 
> Best regards
> 
> Michael
> 
> [ ... ]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 


-- 
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