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] Re: ODF Conformance

Hi David,

wouldn't it be an option to store the formatting properties in question 
as application settings? This would clearly identify them as being 
application specific. You may use the name of the style in the settings 
to identify the style to which them belong. And to identify a frame, you 
can use either its name, or its xml:id.

Best regards


On 06.02.09 11:18, David Faure wrote:
> On Wednesday 04 February 2009, you wrote:
>> Hi David,
>> I'm wondering how your thoughts are currently regarding ODF conformance, 
>> and the discussion on the TC list.
>> If I understand correctly, originally you were concerned that the new 
>> conformance language would eliminate some extensions that KOffice wrote 
>> into documents.  Michael's latest proposal allows extensions in 
>> <style:*-properties> and under <office:meta>.  Does that address your 
>> concerns?
> Yes, I think so. Well, I found a case where we added a custom attribute to
> draw:frame, but obviously we could move that into its style and then it would be a
> <style:*-properties> extension. Code-wise it was much easier to set it as an
> attribute of the draw:frame though (and here again it was _for_ interoperability,
> not against it - the "dummy" frame is created so that other OASIS applications
> can render this case correctly, and the attribute is there so that KWord removes
> the dummy frame on loading since _it_ doesn't need it).
> But most people on the list seem to think that "extensions" == "loss of interoperability",
> including you:
>> However bad you think interoperability 
>> would be in that case, you must admit that it is made worse, not better, 
>> by extending the documents with private schemas. 
> This is sometimes true, sometimes not, as in the above case where the producer
> transforms something into standard OpenDocument at writing time but needs
> a flag to recognize this at loading time as something it can render in a better way
> than the "standard" way. Or in the cases that Dennis detailed.
> To put it simply: yes, extensions kill interoperability *if* the things written out as
> extensions were supposed to be interoperable (or if they really get in the way,
> like in <foo:bar> example). But sometimes that's not the case, carefully written
> extensions are useful and harmless. We want those, and we don't want the
> harmless ones, so forbidding all of them is not a good solution.
> You also wrote:
>> if we allowed some kinds of extensions in strict, 
>> then what do we call a document that has no extensions?
> The question implies that we want to make a distinction. IMHO we don't,
> when it's about harmless extensions. Like style properties. Let producers
> add tiny private attributes in styles without calling them "not compliant".
> But yes, do call "not compliant" a producer that generates <foo:bar><text:p>[....],
> that kind of stuff is bound to create trouble in the consumers.
> You'll note that style attributes do not create any of the issues you listed
> (antivirus scanning, scripts, personally-identifying data, indexing text,
> translating etc.). I certainly do agree that all those things are reasons against
> "bad" extensions, but since we do have all of these things (scripts, metadata, text)
> in the spec already, there's no need to use extensions for those.
> The point of extensions is to use them for the stuff that is NOT in the spec :-)

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]