Re: [office] ODF 1.2 Single-Level Conformance and Law of UnintendedConsequences

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi,

On 01/19/09 20:11, robert_weir@us.ibm.com wrote:
> "Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 01/19/2009 
> 01:10:56 PM:
> 
>> 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].) 
>>
> 
> Agreed.  We need to know what the schema would look like from this change. 
>  Are we removing all foreign attributes and elements, or keeping the 
> specifically enumerated ones but eliminating the boundless case?  I don't 
> think Michael's written proposal addressed that question specifically.

That's indeed a good point. The current strict schema does not allow any 
foreign elements and attributes. The non-strict schema allows foreign 
elements and attributes within metadata and the formatting properties 
elements.

If we define a loosely conformance level, then we can use the current 
strict schema as single basis for both conformance levels, because the 
extensions that ODF 1.1 allows within metadata and formatting properties 
are just a special case of the more general concept of a loose 
conformance. There is no need to express this one time in the 
conformance clauses, and a second time in the schema.

If we have a single conformance level then we need to decide whether we 
anyway want to allow extensions within metadata and formatting properties.

As for metadata, my personal opinion is that authors should use RDF/XML 
metadata instead. The TC has accepted this proposal, and I don't see 
much value in having two alternative ways to achieve the same thing. 
Actually, having two alternative ways only makes consuming 
implementations more difficult, because they have to support both ways.

As for the formatting properties I'm a little bit undecided. I think we 
should in any case have one conformance level there no extensions are 
allowed. We may think of an additional level where extensions are 
allowed within formatting properties only, but actually I'm not sure if 
this is really of as much value that we should have an own conformance 
level for this.

Best regards

Michael

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