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 UnintendedConsequences

Hi David,

On 01/21/09 02:05, David Faure wrote:
> On Tuesday 20 January 2009, robert_weir@us.ibm.com wrote:
>>  But holding back the label of "conformant" is the primary 
>> way to bring vendors to the table to propose and document such features. 
>> If we just label everything conformant, than why would a vendor trouble 
>> with the time and effort to get their proposals accepted formally into the 
>> standard?  Why buy the cow when you can get the milk for free?
> I understand that. But on the other hand, why should an implementation
> be marked as "non-conformant" just because it adds one tiny attribute
> in a style somewhere for mostly internal reasons?
>> But your point on editing hints versus content extensions is well taken. 
>> Maybe there is some way we can formulate a conformance clause that takes 
>> account of that.  But I'd rather have an extension framework that handles 
>> things like that in a structured way than to allow any XML anywhere.
> Right, in fact I think that allowing extensions in style properties is a given,
> while indeed allowing any element in the middle of content elements
> would just open the door to non-standard content. I think your ideas work
> well together: by only allowing extensions inside style properties, only
> additional settings to _existing_ content elements can be added, no actual
> new content.

ODF 1.1 has the concept of the foreign elements, and in addition, the 
non strict schema allows arbitrary elements and attributes within styles 
and metadata. My conformance proposal indeed treats both features the 
same. Maybe that is a mistake.

So, it seems to me that you have no objections to disallow foreign 
elements and attributes everywhere but to still allow them within 
styles. That's something we of cause may do.

There are many options how we could achieve this. A few of them are:

a) We keep the strict and the non-strict schemas, where the difference 
is that the non-strict schema allows arbitrary content in styles (or 
formatting perties elements, to be more precise). We then define two 
conformance levels. A strict conforming document is one that validates 
against the strict schema, and a conforming document, is one that 
validates against the non-strict schema.
b) Like a), except that we call the "strict conforming" documents 
"conforming" in the future, and the other ones "loosely conforming".
c) We define a single schema and a single conformance mode, which allows 
foreign elements within formatting property elements, and only there.
d) Like c), except that we declare the use of foreign elements within 
formatting properties to be deprecated. This would allow a smooth 
transition of extensions into either attributes/elements in the 
standard, or into some other extensibility mechanism.

Does any of these options make sense to you, or others?

Best regards


> Of course styles can affect rendering as well as editing, but that's the
> impossible-to-draw line.

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]