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

> 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

> -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
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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]