[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Conformance Definitions
Hi Rob, On 02/02/09 15:19, robert_weir@us.ibm.com wrote: >> robert_weir@us.ibm.com wrote: >> >>> You have not argued that such extensions should be conformant, only > that >>> they may be useful. I think these are two very different things. It > is >>> not a requirement that an ODF document should be capable of all useful > >>> things, whether defined by the ODF standard or not. It is only > required >>> that the ODF Standard define what exactly a conformant ODF doc is. >> I see one big problem here. The current draft of ODF 1.2 conformance >> definition is not compatible with ODF 1.0 (and ISO/IEC 26300:2600). I >> don't think that users ODF 1.0 who use foreign element/attributes for >> their extension data will applaud to our TC for ignoring investments to >> their infrastructure in a good faith in a continued evolution of ODF. >> > > There are two products defined by the ODF standard: documents and > producers/consumers. My reading of Michael's conformance proposal is that > all conformant ODF 1.0 documents will remain conformant ODF 1.2 documents, > and a subset of conformant ODF 1.0 documents will be conformant to the > strict class of ODF 1.2 documents. So no user of ODF 1.0 who has > conformant ODF 1.0 documents will see their documents become > non-conformant. Formally, a conforming ODF 1.0 document is not a conforming ODF 1.2 document, because the value of the version attribute has changed. But I believe that was not what you wanted to say. What I assume what you wanted to say that a conforming ODF 1.0 document gets a conforming ODF 1.2 document by adapting the version number. So, with that understanding, then your description is valid for the previous proposal (7th iteration), where we had a conformance and a loose conformance for documents. With the current proposal (8th iteration), there is a class of documents that were conforming ODF 1.0 documents, but cannot be made conforming ODF 1.2 documents by just adapting the version number. These are documents that contain foreign elements and attributes within other elements than <office:meta> and <style:*-properties>. > > However, the producer products, the applications that produce ODF, now in > ODF 1.2 have the additional requirement that they are able to produce > conformant strict ODF 1.2 documents. It doesn't say that they cannot also > produce extended ODF 1.2 documents. It only says that they must be able > to produce strict documents. That's true, with the limitation that extension can only occur in the elements I have mentioned above. > > Also, any conformant ODF 1.0 document or application, if unchanged, will > remain for all eternity a conformant ODF 1.0 document or applications. We > can't take that away. This is a very important point. With traditional DTDs, documents contained a DOCTYPE declaration, which defined to which DTD the documents conformed. For HTML, there for instance is a DTD for HTML 3.2, and one for HTML 4 (well, there are multiple for HTML4, but that does not matter here). An HTML document references exactly one of these DTDs by a public identifier. Which means, it is either an HTML 3.2 document, or and HTML 4 document, but never both. And if it is an HTML 3.2, then only the 3.2 specification matters for the document. The same applies for HTML 4 documents. Relax NG does not define how schemas are assigned to instances, but of cause, the situation here is also that a document is a conforming ODF 1.0 document, or a conforming ODF 1.2 document, but never both. > >>> I think it is instructive to look at the W3C XHTML Recommendation. It > >>> defines an extensibility mechanism, via XML namespaces, but does not >>> permit such extensions in conformant documents. >> I don't think that XHTML is really good example here. If you speak with >> people involved in XHTML creation they today have different opinion on >> usefulness of conformance and strict conformance as used in XHTML -- it >> was one of reasons why XHTML failed -- marketed as extensible but made >> in-extensible by law. >> > > I've heard differently. I've heard that XHTML did not take off because > HTML browsers and producers were so lax with enforcing the syntax of HTML > that we ended up with billions of web pages that were not even valid HTML. That is my observation as well. I don't know what the situation is today, but at least 10 years ago, most web pages were not valid HTML. Maybe the situation has changed, but if so, only because users request that HTML documents are not just a flow of HTML tags, but valid and conforming documents. > Once the cat is out of the bag, it is hard to get everyone back to using > well-formed and valid markup. I'd like to avoid that problem with ODF by > having a strict conformance requirement now, rather than try (and fail) to > add it 10 years later. I agree to that. Maybe it is too drastic to remove a conformance level that allows foreign elements and attributes everywhere from one version to another, but I think the direction we take should be towards to conformance definitions that are mote strict rather than loose. > >>> Similarly, OOXML defines >>> some extensibility mechanisms, like custom import parts, but not in >>> conformant documents. I don't think anyone is denying the usefulness > of >>> an ODF extensibility mechanism, or even whether the extensibility >>> mechanism should be defined in the standard, but only whether such >>> mechanisms may be used in conformant documents. >> If there should be strict conformance in ODF to support simplistic >> applications that do not have to take care about foreign extensions then >> there should be also another conformance level which will allow foreign >> elements/attributes and will guarantee roundtripping of them. >> > > OK. I believe Michael's proposal has that. He has two conformance > classes for documents, one which is strict and once which is merely > labeled "conformant" (maybe we should call it "loose"?). The difference > is that the conformant producers of ODF are required to be able to produce > strictly conformant ODF 1.2 on demand. In other words, they are required > to allow the user of the producer the option of whether they want to > extend their documents or not. I think giving the user the choice is > important. Do you see a problem with this? Well, the most recent proposal allows extension only at the elements I mentioned, but the last but one did allow them everywhere, but called these documents indeed "loose conforming". Maybe we should take this as basis for future discussions. This would mean that we have a conformance level which does not allow foreign elements and attributes, and a loose conforming level that does allow them, and further the requirement that a conforming producer must be able to produce conforming documents, that is, documents that do not allow foreign elements and attributes. What do you think? Best regards Michael > > > -Rob > >> Jirka >> >> -- >> ------------------------------------------------------------------ >> Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz >> ------------------------------------------------------------------ >> Professional XML consulting and training services >> DocBook customization, custom XSLT/XSL-FO document processing >> ------------------------------------------------------------------ >> OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member >> ------------------------------------------------------------------ >> >> [attachment "signature.asc" deleted by Robert Weir/Cambridge/IBM] > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]