[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 UnintendedConsequences
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]