[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Regarding Conformance Clauses
I don't understand the preoccupation with tooling. The ODF specification is clearly implementable because people have done so. How foreign elements are dealt with, if encountered, is also something implementations have dealt with. Of course the stipulation has to be made in prose. It is not possible to know what someone who did want to accept somehow-known foreign elements would modify their acceptance schema to allow specific ones, and we won't know how the added-element and attribute schemas merge into the strict schema. We also don't know how they handle ones they don't know about but they want to be graceful with. If we only provide strict schemas, RelaxNG validators will presumably not assess documents having anything else as conformant. That strikes me as fine. Assessing documents that have foreign elements and attributes is a matter for those who want to assess such documents. I am going to presume that where there's a will, there's a way. With regard to the specific behavior of adjusting to the presence of foreign elements and attributes in accepting and processing a document, I assume that there is sufficient implementer ingenuity in the world to handle that if it is desired. We have, after all, been operating with that definition since 2005 and there is no evident harm. - Dennis PS: I see no reason to make contortions to satisfy a specific tool. That is far removed from the purpose of the ODF specifications, it seems to me. In particular, there seems to be no concern that NVDL cannot verify that the office:mimetype attribute value and the <office:body> content agree. (Or the similar question concerning the MIMETYPE item of the package and the <office:body> element of the <office:document-content> element of the content.xml part.) PPS: I don't understand the argument for flipping the default and also deprecating the office:process-content attribute. Validity doesn't depend on whether the content is processed or not. My understanding of the validity requirement in ODF 1.1 is that there be a schema-conformant document left when the element is ignored. (I assume that means the start and end tags are ignored and this process is repeated as necessary in the content that remains.) -----Original Message----- From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] http://lists.oasis-open.org/archives/office/200901/msg00185.html Sent: Monday, January 26, 2009 06:24 To: dennis.hamilton@acm.org Cc: 'OpenDocument Mailing List' Subject: Re: [office] Regarding Conformance Clauses [ ... ] Let me explain this a little bit further. Foreign elements cannot be validated with Relax-NG. That is, one cannot write a Relax-NG schema that allows the embedding of foreign elements anywhere while it at the same time still validates the elements and attributes defined by ODF, and their nesting. That's why we describe how these elements are processed in prose. With NVDL it would be possible to write a script that allows a validation of the ODF documents even if it contains foreign elements. But there is still a problem with office:process-content. Depending on it's value, a NVDL script would have to specify that the content of the element that has to be validated or has to be ignored. While NVDL has these two modes, it can't select the one or the other based on an attribute value. It can only select one or the other mode based on element paths. So, while NVDL would allow us to specify whether the content of an element is processed for the purpose of validation or ignored, it does not allow us to make this decision based on an attribute value. Which means that, if we keep the office:process-content attribute, that we still cannot develop an NVDL script that validates ODF with foreign elements. The deprecation of this attribute therefore is a step into the direction where we can use NVDL for validating ODF documents. And the future use of NVDL is actually the reason why I have proposed to deprecate this attribute. [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]