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] The Rule of Least Power


first of all, I would like to indicate that I support Rob's position 
that we should provide the "least powerful" extensions in the future. I 
have provided several examples where the advantages of this are or where 
the difficulties of allowing arbitrary elements and attributes 
everywhere are.

Anyway, the most recent proposal for conformance clauses, which does 
work for me as a solution for ODF 1.2, has two conformance classes, 
where one allows foreign elements and attributes. This is named 
"extended conformance". In so far, there is a conformance class which 
KOffice documents meet, even if they contain extensions. The situation 
is not really different from ODF 1.1, where we had already a strict 
schema, and where an application could claim to conform to this strict 
schema if and only if does not add foreign elements and attributes. The 
only difference is that we now provide proper names for the individual 
levels of conformance, that we do better describe them, that we have 
removed redundancies and that we have cleaned them up a little.

Something else that we should consider in this discussion is that a more 
strict conformance of OpenDocument documents is nothing that we are 
discussing because Rob or I do like that, but because there is a demand 
for this from users and organization that want to adopt ODF. I'm 
therefore very sure that if the conformance criteria  for (non-extended) 
documents gets less strong, then we then get a demand for a stronger 
level. Which means, regardless how we define or name the individual 
conformance levels, there will be a level which documents that contain 
extensions won't meet.

Best regards


On 02/12/09 15:24, Thomas Zander wrote:
> On Thursday 12. February 2009 13:53:02 ext robert_weir@us.ibm.com wrote:
>>> That mail just posts some anonymous element; thats not a usecase.
>>> I can't even argue that the "foo:bar" is or is not a loss if an
>>> implementation
>>> ignores it since you don't give a realistic usecase to argue from.
>> But that's the important point.  From the perspective of an general ODF
>> consumer, say a word processor, these private extensions are opaque,
>> without any discernible semantics, just like foo:bar.
> yes, thats the point of adding data that is not in the ODF spec. Its private 
> data required by the implementation to not loose information.
> Can you give me any usecase where any type of extention would be useful to any 
> implementation that is not the one that wrote it?
> Or, in other words; what advantage does it give us to move this private data 
> to pre-defined extention positions?
> Do note that we already *have* pre-defined extension positions, specifically 
> metadata. So this is not about adding some metadata that I'd like to survive 
> a simple load/save by a random ODF implementation. Thats a solved problem.
>>> I'd rather call a real usecase where things go really wrong 'proof' ;)
>> The entire point of my criticism is that the consumer of an extended
>> document just sees arbitrary XML.  It has no knowledge of use cases, of
>> what that extension is for.  It just sees foo:bar.  It is a black box.
> Yes, and there is nothing you can do to open that black box. If KOffice or Qts 
> ODFWriter decides it needs to store some data to make saving loading to its 
> native format not loose info, and that information doesn't fit in any ODF 
> tag, then you get a black box.
> Thats a fact of life. Arguing thats a bad idea is equivalent to saying we need 
> to document each and every possible piece of data in the ODF specification. 
> And I think we don't want that. Do we?

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]