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] ODF 1.2 Single-Level Conformance and Law of Unintended Consequences


Thanks Rob,

With regard to current allowances of implementation-defined features, the
choice of schema matters.  The "strict" schema actually removes some areas
where implementation-defined extensions were explicit in the schema itself.
(And, for a different example, I assert that it is a feature, not a
limitation, to have omission of table:protection-key-digest-algorithm mean
that the hash function that produces the table:protection-key is
implementation defined [and also upward-compatible from 1.1 as well].)  

If we leave the non-strict schema as the only one, that is a different story
since it is the schema against which Conforming Document is defined in 1.1.
Also, the appearance of optional arbitrary metadata elements and
style:*-properties is explicit in the schema and in the 1.1 conformance
clause, which goes on to say that a conformant processor should preserve
such material.

I don't see this language in the current conformance clause.  So that is
something we need to be clear about with regard to 1.2 and the chosen
schema.

I think this is like one of those strict-constructionism debates.  I have no
idea why these provisions and the foreign element provisions are in ODF
1.0/1.1, nor the problems that were being addressed.  I can see benign and
valuable uses of them, but that is an academic point.  I just don't like
fixing something by breaking it.  With regard to interoperability, I don't
think the issue is even close to hinging on what the spec says a conformant
document is, strictly or loosely.

I must remember to point out that there is no advice around what it means to
provide no semantic support for something that is part of a conformant
document, while there is clear advice around dealing with an unrecognized
foreign element.  It would be nice to be able to say that if no semantic
support is provided for a feature of a conformant document, the processor
should treat it using the rules for foreign elements and  attributes.  This
also works for unrecognized features using ODF-specified namespaces too.
(The office:process-content advice could be extended for that as well,
rather than deprecated.)

 - Dennis

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 

Sent: Monday, January 19, 2009 09:18
To: office@lists.oasis-open.org
Subject: Re: [office] ODF 1.2 Single-Level Conformance and Law of Unintended
Consequences

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 01/19/2009 
11:44:34 AM:

> 
> That was a very interesting discussion on conformance with regard to
> having a single-level conformant document.
> 
> I want to reaffirm that, with the single-level approach, we need to 
> deal with all of those places where implementation-defined features 
> are allowed.  (Another example is in the use of alternative 
> renditions and objects where there is currently no specification of 
> MIME types for recognized ones.)
> 

The TC may certainly address other areas where ODF currently has 
implementation-defined features, but I wouldn't say this is a necessity. 
Remember, the proposal for "loosely conformant" documents dealt with only 
a single dimension of extensibility, that done by the allowance of foreign 
elements and attributes.  If we do not allow such extensions in conformant 
ODF 1.2 documents, then the status quo with regards to other 
implementation-defined behaviors remains unchanged unless the TC wishes to 
address those areas separately.

[ ... ]



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]