[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 removed. 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 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.] 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: http://lists.oasis-open.org/archives/office/200810/msg00105.html Best regards Michael [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]