Hi,
On 01/19/09 20:11, wrote:
> "Dennis E. Hamilton" <> 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
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
