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 simple proposal

Hi Florian,

regarding an ODF 1.0 errata:

When approving an errata, section 3.5 of the TC Process[1] requires that 
we are

"Confirming by Full Majority Vote that the proposed corrections do not 
constitute a Substantive Change."

where "substantive changes" are defined in section 1 as follows:

""Substantive Change" is a change to a specification that would require 
a compliant application or implementation to be modified or rewritten in 
order to remain compliant.".

So, regardless whether we maybe should have allowed the attribute 
combination in question already in ODF 1.0, we must include this 
combination only if we believe that this does not require that any 
existing implementation is changed. If we believe that existing 
implementations must be changed, then we must not include the new 
combination into an ODF 1.0 errata.

Best regards


[1] http://www.oasis-open.org/committees/process.php

Florian Reuter wrote:
> Hi,
> I think the right thing to do is to:
> a) add the two "X" to ODF1.2
> b) add the two missing "X" to the ODF1.0/1.1 erata, since this is not a new feature, but an error in ODF1.0/1.1
> c) define what should happen if the combination is not valid in ODF1.2
> d) add an erata for ODF1.0/ODF1.1 to define what should happen if the combination is not valid
> Then we should start the more general discussion of what an application should do if it finds something "undefined",
> because: Whats the point of having a specification which has undefined behaviour.
> What we should *not* do IMHO is: Add the two "X" to ODF1.2 and leave it "undefined" for ODF1.0/1.1, since I believe its
> not a new feature in ODF1.2 but rather an error in ODF1.0/ODF1.1.
> Additionally we should spend at least a second reviewing the other combinations. It would be bad if we would find out in
> a couple of days that we need to chance it again..
> ~Florian
>>>> Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems <Oliver-Rainer.Wittmann@Sun.COM> 07/14/08 1:22 PM >>>
> Dear Florian
> Florian Reuter wrote:
>> Regarding the „simple proposal“ Michael tried to push through last meeting I have the following concerns:
> Michael is not pushing this proposal. It is me who is pushing this proposal.
>> a) I do not think it’s the most complex proposal in the world, but I think there are some open questions. 
> Ok. No problem.
>> b) I’m concerned with the way Sun tries to push this through. I think its bad style not giving me the time in the TC
> to
>> explain my points. Calling the agenda item 30sec before closing the meeting and trying to vote on it is bad style.
>> Furthermore giving the TC the impression that I’m the troublemaker because this is just a simple proposal is not very
>> kind.
> The proposal has been contributed at 2008-06-02. In the following two TC 
> calls the members have been asked for comments and questions.
> On the call on 2008-06-23, when we wanted to vote on it, you had 
> concerns regarding backward compatibility. We agreed that I send some 
> text to the mailing list. Due to mail problems I posted this text on 
> 2008-07-01, but I gave a summary in the TC call on 2008-06-30.
> There was discussions on the list regarding your general request about 
> handling of undefined property values.
> Thus at the end, there was enough time to express your concerns.
> Nevertheless, we can discuss your concerns now, as you obviously did not 
> find the time before.
>> My open questions:
>> a) Why should we add the two “X” to the table. Why only these? Why is text:anchor-type=”paragraph” and
>> style:vertical-rel=”frame” not valid?
> The answer to these _new_ questions - you never expressed them before, 
> neither in a TC call nor on the mailing list - is:
> - Look at my proposal text:
> <quote>
> ...
> They are needed to have objects (text frames, graphics, embedded objects
> and drawing objects) anchor to a certain content (paragraph or
> character), but be vertical positioned relative to the page areas. E.g.,
> a graphic explaining a certain word of a paragraph always vertical
> positioned at the bottom of the page, on which the word is on.
> ...
> </quote>
> - Currently, I do not think that we need the others.
> - I do not know. Probably, such a combination makes sense. Until now I 
> did not think of this combination.
>> b) I would not know how to implement the proposal in a reader which supports ODF1.0/1.1 and ODF1.2. Consider the
>> following pseudo-code fragments:
> I think this question/comment/concern is irrelevant and can not be 
> solved, because as you already notice, in ODF 1.0/1.1 it is not defined, 
> how an ODF 1.0/1.1 supporting application should react on forbidden 
> combinations. Thus, it is not possible to define such a behavior in ODF 
> 1.2 for ODF 1.0/1.1 supporting application.
> Note: As I already stated, I can support your request for such a 
> definition for the ODF 1.2 supporting applications. Thus, that these 
> applicatio
> n will know how to handle unknown or disallowed property values.> if (text:anchor-type=”paragraph” and style:vertical-rel=”page”) then
>>    // use text:anchor-type=”paragraph” and style:vertical-rel=”page” regardless of the ODF version
>> end
>> Or one could implement it as 
>> if (text:anchor-type=”paragraph” and style:vertical-rel=”page”) then
>>    if (odf:version=”1.2”) then 
>>       // use text:anchor-type=”paragraph” and style:vertical-rel=”page”
>>    end
>>    if (odf:version=”1.1” or odf:version=”1.0”) then 
>>       // in ODF 1.0 or ODF 1.1 this was not allowed; so we need to behave like a ODF1.0/1.1 reader
>>       // here it is unclear which values should be used…
>>    end
>> end
>> The implications for interop are huge. 
>> ~Florian

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]