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