OASIS Open Document Format for Office Applications (OpenDocument) TC

Hi David,

in our last TC call we have discussed the question whether we want to 
add/keep an extension mechanism for formatting properties even for (non 
extended) conforming documents, and I have suggested to proceed with 
this independent of the conformance clauses itself.

My suggestion was that we add the following text to chapter 16:

> The <*-properties> elements may, in addition to the elements and
> attributes defined by the OpenDocument schema, contain elements and
> attributes not defined by the schema. These *shall not* be associated
> with a namespace defined by this specification. The semantics of these
> elements and attributes are implementation defined. They *shall not*
> influence how the document is displayed, but *may* be evaluated when the
> document is modified, for instance, when the properties of an object are
> modified or new objects are inserted. 

While it has been suggested to remove the last sentence, I still think 
we should keep it, or something similar, because otherwise we would 
allow adding formatting properties that may have any kind of influence 
on the display of a document. This would be in so far and issue, as 
there is no strict conformance anymore, which explicitly forbids these 
attributes.

So, this still would be my proposal. However, if I read the mails from 
Thomas Zander, it is not clear to me whether this extension mechanism 
alone would be sufficient for KOffice, or whether there are other 
extensions that are outside formatting properties. I would further like 
to point out that there still is a conformance mode that allows foreign 
elements and attributes anywhere, which as been renamed to "extended 
conformance", and that the case we are discussing here is just a special 
case of that conformance mode.

Taking it all together, it seems to me that you are in a much better 
position than me to decide whether this extension would be useful for 
KOffice, and also how the precise wording could be to meet the scope of 
KOffice's extensions. Provided this is okay for you, I therefore would 
like to ask you care about this proposal if you think that's reasonable. 
It of cause is fine for me if you would just adopt my suggestion.

I will put this on the agenda for Monday.

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

On Thursday 12 February 2009, Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> My suggestion was that we add the following text to chapter 16:
> 
> > The <*-properties> elements may, in addition to the elements and
> > attributes defined by the OpenDocument schema, contain elements and
> > attributes not defined by the schema. These *shall not* be associated
> > with a namespace defined by this specification. The semantics of these
> > elements and attributes are implementation defined. They *shall not*
> > influence how the document is displayed, but *may* be evaluated when the
> > document is modified, for instance, when the properties of an object are
> > modified or new objects are inserted. 
> 
> While it has been suggested to remove the last sentence, I still think 
> we should keep it, or something similar, because otherwise we would 
> allow adding formatting properties that may have any kind of influence 
> on the display of a document. 

I have since realized that forbidding any influence on the display is wrong,
there are many features which might "appear in a way", I see no reason to
forbid them. Like Florian said: there is no definition of the way an ODF document
should be layouted and rendered even now in the standard, so it doesn't
make sense to "prevent changes in the display", when the display itself is
undefined in the first place...

I guess what you meant to say was that it's better to standardize attributes
that have their place in the standard, and I think we all agree on that.
My examples of koffice-1.1 extensions to ODF were agreed as "not harmful"
because they had no influence on the display, only on editing, but this is
just one special case, surely there are tons of "not harmful" extensions
possible that would still influence the display, as long as it's just extra
features -- indicators, etc.
Imagine an attribute related to a specific implementation of spellchecking...
it will influence the display of the document (red underline), but yet it
won't harm interoperability.

> This would be in so far and issue, as  
> there is no strict conformance anymore, which explicitly forbids these 
> attributes.

I don't understand this sentence.

> So, this still would be my proposal. However, if I read the mails from 
> Thomas Zander, it is not clear to me whether this extension mechanism 
> alone would be sufficient for KOffice, or whether there are other 
> extensions that are outside formatting properties. 

Ah, let me clear up this confusion. I was listing the extensions I created for
KOffice-1.1.x, while Thomas is talking about the extensions necessary for
KOffice-2.0. I'm the expert on ODF in 1.1, he's the expert about 2.0.
If our statements seem contradictory, it's only because we are not 
knowledgeable about the same version of KOffice :-)

So, for KOffice-1.1.x, *-properties extensions is enough, while Thomas
showed examples of other extensions needed for KOffice-2.0.

> I would further like  
> to point out that there still is a conformance mode that allows foreign 
> elements and attributes anywhere, which as been renamed to "extended 
> conformance", and that the case we are discussing here is just a special 
> case of that conformance mode.

Right. The question is what difference does it make in practice, whether a document
is conformant to the strict conformance or to the extended conformance.
I just don't want KOffice documents to be treated as second-class citizens....
but I admit that I don't know what difference it really makes.
I fear the day where e.g. OOo refuses to fix a bug coming from a koffice-created
document just because it is not "strictly" conformant for unrelated reasons
(i.e. the bug would be totally unrelated to any koffice extensions, but the first
thing people will see is "OK, the problem probably comes from the document
since it's not strictly conformant")... You see what I mean by 2nd-class citizens :)

> Taking it all together, it seems to me that you are in a much better 
> position than me to decide whether this extension would be useful for 
> KOffice, and also how the precise wording could be to meet the scope of 
> KOffice's extensions. Provided this is okay for you, I therefore would 
> like to ask you care about this proposal if you think that's reasonable. 
> It of cause is fine for me if you would just adopt my suggestion.

I'm not sure what you mean by "care about the proposal", I think we all care
about what happens with it. My proposal would simply be like yours but
without the last sentence, i.e.:

 The <*-properties> elements may, in addition to the elements and
 attributes defined by the OpenDocument schema, contain elements and
 attributes not defined by the schema. These *shall not* be associated
 with a namespace defined by this specification. The semantics of these
 elements and attributes are implementation defined. 

-- 
David Faure, faure@kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

Hi David,

On 02/12/09 18:12, David Faure wrote:
> On Thursday 12 February 2009, Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
>> My suggestion was that we add the following text to chapter 16:
>>
>>> The <*-properties> elements may, in addition to the elements and
>>> attributes defined by the OpenDocument schema, contain elements and
>>> attributes not defined by the schema. These *shall not* be associated
>>> with a namespace defined by this specification. The semantics of these
>>> elements and attributes are implementation defined. They *shall not*
>>> influence how the document is displayed, but *may* be evaluated when the
>>> document is modified, for instance, when the properties of an object are
>>> modified or new objects are inserted. 
>> While it has been suggested to remove the last sentence, I still think 
>> we should keep it, or something similar, because otherwise we would 
>> allow adding formatting properties that may have any kind of influence 
>> on the display of a document. 
> 
> I have since realized that forbidding any influence on the display is wrong,
> there are many features which might "appear in a way", I see no reason to
> forbid them. Like Florian said: there is no definition of the way an ODF document
> should be layouted and rendered even now in the standard, so it doesn't
> make sense to "prevent changes in the display", when the display itself is
> undefined in the first place...

Well, maybe the above sentence does not really say what I mean. What I
mean is that KOffice should display a document the same, regardless
whether a foreign attribute is present or not. The same would apply to
OpenOffice.org, if it would have such attributes. But KOffice or
OpenOffice.org may display documents differently anyway.

So maybe it is clearer to say

"A conforming consumer *shall* display a documents that contains a
particular element or attribute not defined by this specification, as it
would if the element or attribute would not be present."

> 
> I guess what you meant to say was that it's better to standardize attributes
> that have their place in the standard, and I think we all agree on that.

Yes, that is in any case the best solution.

> My examples of koffice-1.1 extensions to ODF were agreed as "not harmful"
> because they had no influence on the display, only on editing, but this is
> just one special case, surely there are tons of "not harmful" extensions
> possible that would still influence the display, as long as it's just extra
> features -- indicators, etc.

I think it is very difficult to draw a line between "harmful" and "not
harmful". One may also consider it to be "not harmful" if a different
font or font size is used, because the content of the document remains
the same.  But for someone, it may make a difference whether an 
indicator is displayed or not,

Anyway, there may be a better description of what is allowed and what 
isn't, but I think there must be one. Otherwise, an application could 
add non-standardized formatting properties that heavily influence how 
the document is displayed, and could call itself conforming anyway.

> Imagine an attribute related to a specific implementation of spellchecking...
> it will influence the display of the document (red underline), but yet it
> won't harm interoperability.

For these kind of thing we have the application settings.
> 
>> This would be in so far and issue, as  
>> there is no strict conformance anymore, which explicitly forbids these 
>> attributes.
> 
> I don't understand this sentence.

What I mean is that for ODF 1.1 one can validate a document against the 
strict schema, and then does know that there are no extensions. If we 
allow arbitrary formatting properties in the single ODF 1.2 schema, then 
this is not possible any longer.

> Ah, let me clear up this confusion. I was listing the extensions I created for
> KOffice-1.1.x, while Thomas is talking about the extensions necessary for
> KOffice-2.0. I'm the expert on ODF in 1.1, he's the expert about 2.0.
> If our statements seem contradictory, it's only because we are not 
> knowledgeable about the same version of KOffice :-)

Okay. That helps.

>> I would further like  
>> to point out that there still is a conformance mode that allows foreign 
>> elements and attributes anywhere, which as been renamed to "extended 
>> conformance", and that the case we are discussing here is just a special 
>> case of that conformance mode.
> 
> Right. The question is what difference does it make in practice, whether a document
> is conformant to the strict conformance or to the extended conformance.
> I just don't want KOffice documents to be treated as second-class citizens....
> but I admit that I don't know what difference it really makes.
> I fear the day where e.g. OOo refuses to fix a bug coming from a koffice-created
> document just because it is not "strictly" conformant for unrelated reasons
> (i.e. the bug would be totally unrelated to any koffice extensions, but the first
> thing people will see is "OK, the problem probably comes from the document
> since it's not strictly conformant")... You see what I mean by 2nd-class citizens :)

First of all, this situation could easily be avoided by using a bug 
document that does not contain the extension. Bug documents should be as 
simple as possible. Which means that, if the extensions is not the root 
cause of the bug, then it should not be in the bug document.

In practice, it of cause may happen that particular extensions are 
stored by default and therefore are contained in all documents. In this 
case it should be sufficient to remove it when someone really refuses to 
fix a bug because of it.

But I think your example shows the problem that arises from such 
extension mechanism where it is not clearly defined what the extensions 
are about, and how they relate to the markup the ODF specification 
defines. A developer who gets an ODF document with foreign elements and 
attributes does not know what these do. She or he cannot know by just 
looking that the document and loading it into the own application 
whether these can be the root cause of a bug.

If the bug is a crash, then it may be sufficient to remove them. But if 
the bug is in the "displays wrong" category then this does not help. The 
document will "display wrong" regardless whether the foreign elements 
are there, because they are not interpreted. But how would be bug doc 
look in the application that did create the document if the foreign 
elements and attribute are not present. Would it still displayed the 
same? To figure out that the extensions are really not the root cause, 
she or he would have to remove them, and would have to load the document 
into the other application to see how the document looks then. If this 
is KOffice, that would work, although it is some effort. But what if the 
other application is a commercial product?


> 
>> Taking it all together, it seems to me that you are in a much better 
>> position than me to decide whether this extension would be useful for 
>> KOffice, and also how the precise wording could be to meet the scope of 
>> KOffice's extensions. Provided this is okay for you, I therefore would 
>> like to ask you care about this proposal if you think that's reasonable. 
>> It of cause is fine for me if you would just adopt my suggestion.
> 
> I'm not sure what you mean by "care about the proposal", I think we all care
> about what happens with it. My proposal would simply be like yours but
> without the last sentence, i.e.:

What I mean is that you become the owner of the proposal.

> 
>  The <*-properties> elements may, in addition to the elements and
>  attributes defined by the OpenDocument schema, contain elements and
>  attributes not defined by the schema. These *shall not* be associated
>  with a namespace defined by this specification. The semantics of these
>  elements and attributes are implementation defined. 
> 

As said above, I'm not feeling comfortable with having no restrictions 
on the extended elements and attributes that are allowed. But this may 
be just me. We may check what others think about this on Monday.

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

On Friday 13. February 2009 09:16:22 ext Michael Brauer - Sun Germany - 
ham02 - Hamburg wrote:
> "A conforming consumer *shall* display a documents that contains a
> particular element or attribute not defined by this specification, as it
> would if the element or attribute would not be present."

In principle I would be fine with this.

The wording needs some work as this might have one problem for non-complete 
implementations (consumers).
Imagine a property (drop caps for instance) that is not supported by an 
implementation, per my reading it would fail the above clause because it 
misses a feature. So its unwanted collateral damage.

But I have no problem with saying the namespaced odf-extensions should not be 
meant to change the rendering of the object in strict docs.

-- 
Thomas Zander

On Fri, 2009-02-13 at 11:06 +0100, Thomas Zander wrote:
> On Friday 13. February 2009 09:16:22 ext Michael Brauer - Sun Germany - 
> ham02 - Hamburg wrote:
> > "A conforming consumer *shall* display a documents that contains a
> > particular element or attribute not defined by this specification, as it
> > would if the element or attribute would not be present."
> 
> In principle I would be fine with this.
> 
> The wording needs some work as this might have one problem for non-complete 
> implementations (consumers).
> Imagine a property (drop caps for instance) that is not supported by an 
> implementation, per my reading it would fail the above clause because it 
> misses a feature. So its unwanted collateral damage.
> 
> But I have no problem with saying the namespaced odf-extensions should not be 
> meant to change the rendering of the object in strict docs.
> 

I don't think that "shall" is appropriate. A consumer should be allowed
to indicate that there is an known tag, especially if we expect the
consumer to retain that tag. Otherwise we may be forcing consumers to
hide information from the user.

Andreas  
-- 
Andreas J. Guelzow, PhD, FTICA
Coordinator, Mathematical & Computing Sciences
Concordia University College of Alberta

Hello Michael,

> So, this still would be my proposal. However, if I read the mails from
> Thomas Zander, it is not clear to me whether this extension mechanism
> alone would be sufficient for KOffice, or whether there are other
> extensions that are outside formatting properties. I would further like
> to point out that there still is a conformance mode that allows foreign
> elements and attributes anywhere, which as been renamed to "extended
> conformance", and that the case we are discussing here is just a special
> case of that conformance mode.

At the moment koffice also uses attributes with namespace koffice to define 
some extra information. These information are used to keep some additional 
information which are nice to have but not necessary to keep when a different 
office application saves the document again. So they do not change a way how 
the document looks when opened by a different application. One of those 
attributes is the koffice:nodeTypes that more closely define what kind of 
node a point in draw:path uses.

We use these to make it possible to save additional data that is not specified 
by the standard.

I agree with Rob here that it would be nice if these values could be kept if a 
different application loads and saves the document. For myself I is also fine 
if an application would strip these attributes.
 
One idea would be to define each foreign attribute and under which cases it 
can be preserved.

I hope that explains a bit more in what way koffice is using additional 
attributes.

Thorsten

2009/2/15 Thorsten Zachmann 

On Sunday 15 February 2009, Dave Pawson wrote:
> 2009/2/15 Thorsten Zachmann 

2009/2/16 Thorsten Zachmann 

On Monday 16. February 2009 15:43:49 ext Thorsten Zachmann wrote:
> > Would you put [the retention of foreign attributes] requirement on 
> > all ODF applications? 
>
> No. I think it is ok for applications to strip all stuff it does not
> support during a load/save. That also happens in koffice.

At least the text module does do a valiant effort to maintain non-supported 
properties.  All ODF specified attributes are meant to get loaded and we 
store them in the document even if the renderer doesn't use them. Then on 
save they are written out again.

So round-tripping oo-writer docs in KOffice should in most cases be lossless 
once we get to the release, at least ;)
-- 
Thomas Zander