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


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..


>>> 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
> 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:
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.

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

Sun Microsystems GmbH    Oliver-Rainer Wittmann
Nagelsweg 55             Software Engineer - OpenOffice.org/StarOffice
20097 Hamburg
Germany                  Fax:   (+49 40) 23 646 550
http://www.sun.de        mailto:oliver-rainer.wittmann@sun.com
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

Oliver-Rainer Wittmann (od) - OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]