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] my requirements


Hi Michael,

would you please consider splitting up R7+(1-6) into seperate requirements; e.g. R7 to R12.

This will ease further discussion --- I guess.

~Florian


>>> Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM> 03/20/07 1:02 PM >>>
All, Florian,

Florian: Thank you very much for posting your requirements.

All: If I remember it correctly, what we have agreed yesterday is that 
we start (or continue) our discussions with first collecting the full 
list of requirements, and that we when check the proposal whether they 
meet these requirements or not. I therefore would like to ask you to 
send in your additional requirements as soon as possible, and to check 
for the requirements that get posted to the list whether it is clear 
what is meant. As soon as I have got the requirements from Thomas, David 
and Oliver I will collect them in a single document, so that we can 
start comparing the proposals against them. If someone else has 
requirements, please do not hesitate to send them to the list as well.

We probably also need to discuss whether we agree or disagree on certain 
requirements, but only for those requirements that are not met by the 
one or the other proposal. I therefore suggest that we delay this 
discussion until we have the status which proposal meets what requirement.

I would like to add one requirement to the list myself. It is one that 
actually applies to all proposals we are discussing, but in order to get 
a list that is as complete as possible, it may be reasonable to add it:

R7. The resulting specification (and therefore each proposal) must meet 
the requirements defined by our charter. These are:

The resulting file format must meet the following requirements:

    1. it must be suitable for office documents containing text, 
spreadsheets, charts, and graphical documents,
    2. it must be compatible with the W3C Extensible Markup Language 
(XML) v1.0 and W3C Namespaces in XML v1.0 specifications,
    3. it must retain high-level information suitable for editing the 
document,
    4. it must be friendly to transformations using XSLT or similar 
XML-based languages or tools,
    5. it should keep the document's content and layout information 
separate such that they can be processed independently of each other, and
    6. it should 'borrow' from similar, existing standards wherever 
possible and permitted.

Best regards

Michael


Florian Reuter wrote:
> Hi all,
> 
> as promised my list of requirements (R1-R6).  David already states that R3 is not important to him.
> 
> ~Florian
> 
> ----------------------------------------
> 
> === R1. Backward compatibility with ODF1.0/ODF1.1 ===
> 
> Whatever changes to the numbering in ODF1.2 are made these changes may only affect the presentation/formatting of the number, but not the number itself. More precice it is acceptable that a number presentation/formatting changes from "1"->"i", "1"->"A", etc. but it is never acceptable that a number ifself is changed.
> 
> === R2. Backward compatibility with "legacy" ODF docs arose from the fact that ODF1.1 wasn't clearly specified ===
> 
> The TC has a responsability to for the „legacy“ ODF documents who where created by applications due to the fact the numbering in ODF1.0/ODF1.1 wasn't clearly specified.
> This responsability includes that the „legacy“ ODF fragments are covered by the ODF1.2 enhancements whithout invalidating them.
> For example the offcial ODF specification ( http://www.oasis-open.org/committees/download.php/19275/OpenDocument-v1.0ed2-cs1.odt) currently countains the following text:list pattern whose behaviour is not clearly specified by the ODF1.0/ODF1.1 specification:
> <text:list style-name="L1">
>    <text:list-item><text:p>P1</text:p></text:list-item>
>    <text:list-item><text:p>P2</text:p></text:list-item>
> </text:list>
> <text:list style-name="L2">
>    <text:list-item><text:p>P3</text:p></text:list-item>
>    <text:list-item><text:p>P4</text:p></text:list-item>
> </texlist-item><text:p>P5</text:p></text:list-item>
>    <text:list-item><text:p>P6</text:p></text:list-item>
> </text:list>
> However the current interpretation of these „legacy“ document by various ODF1.0/1.1 processing entities is
> 1. P1
> 2. P2
> A. P3
> B. P4
> 3. P5
> 4. P6
> 
> === R3. text:numbered-paragraph legacy docs ===
> Another type of legacy docs which arose from the fact that ODF1.0/ODF1.1 numbered-paragraphs are not fully specified are ODF fragments of the following type
> <text:numbered-paragraph text:style-name="L1"><text:p>P1</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:style-name="L1"><text:p>P1</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:style-name="L2"><text:p>P2</text:p></text:numbered-paragraph>
> which are interpreted as
> 1. P1
> 2. P2
> C. P2
> So numbered-paragraphs are treated as if there only exists one counter domain at all.
> 
> === R4. 100% roundtrip fidelity between text:list and text:numbered-paragraph ===
> 
> The current ODF specification states that
> <quote>
> A list in <text:list> representation could be converted into a list in <text:numbered-paragraph> representation and vice versa.
> </quote>
> The use case derived from that is that there should be 100% roundtrip fidelity when converting between numbered paragraph and text:list.
> Actually requires that
> 1.an ODF list in numbered-paragraph respresentation, converted to a text:list representation, converted to a numbered-paragraph represention must result in the same conceptional ODF list a the one before the conversion was started.
> 2.an ODF list in text:list respresentation, converted to a text:numbered-paragraph representation, converted to a text:list represention must result in the same conception ODF list as the one before the conversion was started.
> The roundtrip must be deterministic to not disrupt user expecience.
> 
> 
> === R5. ODF 1.2 numbering should be independent from an applications counter implementation ===
> 
> Applications can basically follow several strategies when maintaining the internal counters. Together with the text:start-value of the list style the choice of the internal strategy may have a serious impact on the resulting numbering.
> The ODF 1.2 numbering should not require a special strategy for an application's counter implementation.
> 
> === R6. Use case for ODF1.2 list-override enhancement ===
> 
> Changing the number formatting of a text:list is current definetly not possible in ODF1.0/ODF1.1.
> ODF1xample the encoding of the following sample should be possible in ODF1.2:
> 1. P1
> 2. P2
> 3. P3
> D. Appendix1
> E. Appendix2
> 
> 
> ------------------------------------------------------------------------
> 
> Oliver's/Thomas'/David's and Michael's proposal contradicts thse requirements in my opinion as state below:
> 
> === R1. Backward compatibility with ODF1.0/ODF1.1 ===
> 
> In ODF1.0/ODF1.1 the following fragment
> Your proposal does not meet that requirement of mine illustrated by the following XML fragment
> <text:list style-name="L1" text:id="id1_1" >
>   <text:list-item><text:p>P1</text:p></text:list-item>
>   <text:list-item><text:p>P2</text:p></text:list-item>
> </text:list>
> <text:list style-name="L1" text:id="id1_2" >
>   <text:list-item><text:p>P3</text:p></text:list-item>
>   <text:list-item><text:p>P4</text:p></text:list-item>
> </text:list>
> <text:list style-name="L3" text:id="id1_3" text:continue-list="id1_1" text:continue-numbering="true">
>   <text:list-item><text:p>P5</text:p></text:list-item>
>   <text:list-item><text:p>P6</text:p></text:list-item>
> </text:list>
> 
> will be interpreted as
> 1. P1
> 2. P2
> A. P3
> B. P4
> 1. P1
> 2. P2
> 
> but according to ODF1.0/ODF1.1 this will be interpreted as
> 1. P1
> 2. P2
> A. P3
> B. P4
> i. P5
> ii. P6
> 
> So this is a clear contradiction to my requirement R1: Backward compatibility with ODF1.0/ODF1.1
> 
> === R2. Backward compatibility with "legacy" ODF docs arose from the facts proposal the following ODF1.0/ODF1.2 "legacy document"
> <text:list style-name="L1">
>    <text:list-item><text:p>P1</text:p></text:list-item>
>    <text:list-item><text:p>P2</text:p></text:list-item>
> </text:list>
> <text:list style-name="L2">
>    <text:list-item><text:p>P3</text:p></text:list-item>
>    <text:list-item><text:p>P4</text:p></text:list-item>
> </text:list>
> <text:list style-name="L1" text:continue-numbering="true">
>    <text:list-item><text:p>P5</text:p></text:list-item>
>    <text:list-item><text:p>P6</text:p></text:list-item>
> </text:list>
> will be interpreted as
> 1. P1
> 2. P2
> A. P3
> B. P4
> 1. P1
> 2. P2
> and not as
> 1. P1
> 2. P2
> A. P3
> B. P4
> 3. P5
> 4. P6
> as done by OOo today.
> 
> === R3. text:numbered-paragraph legacy docs ===
> 
> According to Oliver's/Thomas'/David's and Michael's proposal the following ODF1.0/ODF1.2 "legacy document"
> <text:numbered-paragraph text:style-name="L1"><text:p>P1</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:style-name="L1"><text:p>P1</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:style-name="L2"><text:p>P2</text:p></text:numbered-paragraph>
> is no longer valid, since a text:list-id is required. Nothing is said how document of the above type should be handled.
> 
> === R4. 100% roundtrip fidelity between text:list and text:numbered-paragraph ===
> 
> According to Oliver's/Thomas'/David's and Michael's proposal the following ODF fragment
> <text:list text:style-name="L1">
> <text:list-item text:list-override="L2"><text:p>P1</text:p></text:list-item>
> <text:list-item><text:p>P2</text:p></text:list-item>
> <text:list-item><text:p>P3</text:p></text:list-item>
> <text:list-item><text:p>P4</text:p></text:list-item>
> </test:list>
> 
> would map into
> 
> <text:numbered-paragraph text:list-id="id1" text:style-name="L2"><text:p>P1</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:list-id="id1" text:style-name="L1"><text:p>P2</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:list-id="id1" text:style-name="L1"><text:p>P3</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:list-id="id1" text:style-name="L1"><text:p>P4</text:p></text:numbered-paragraph>
> 
> which then would map back to
> 
> <text:list text:style-name="L2">
> <text:list-item><text:p>P1</text:p></text:list-item>
> <text:list-item text:list-override="L1"><text:p>P2</text:p></text:list-item>
> <text:list-item text:list-override="L1"><text:p>P3</text:p></text:list-item>
> <text:list-item text:list-override="L1"><text:p>P4</text:p></text:list-item>
> </test:list>
> from an applications counter implementation ===
> 
> Thats a hard one to explain :-)
> 
> Basically consider 
> <text:list-style style:name="L1">
> <text:list-level-style-number text:level="1" style:num-format="1" text:start-value="1" text:display-levels="1"/>
> <text:list-level-style-number text:level="2" style:num-format="1" text:start-value="1" text:display-levels="2"/>
> </text:list-style>
> 
> <text:list-style style:name="L2">
> <text:list-level-style-number text:level="1" style:num-format="1" text:start-value="1" text:display-levels="1"/>
> <text:list-level-style-number text:level="2" style:num-format="1" text:start-value="10" text:display-levels="2"/>
> </text:list-style>
> 
> then an application can interpret
> <text:numbered-paragraph text:level="1" text:style-name="L2" text:list-id="2"><text:p>P1</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:level="2" text:style-name="L1" text:list-id="2"><text:p>P2</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:level="2" text:style-name="L2" text:list-id="2"><text:p>P3</text:p></text:numbered-paragraph>
> 
> as
> 
> 1 P1
> 1.1 P2
> 1.1 P3
> 
> 1 P1
> 1.10 P2
> 1.11 P3
> 
> 1 P1
> 1.10 P2
> 1.2 P3
> 
> depending on when the start-value is set. Basically because applications can follow a pre- or post increment strategy here.
> 
> Oliver's/Thomas'/David's a
> 1.1 P3
> 
> out of it, because they use a post increment strategy.
> 
> This is the reason why I permitted the olverloading of text:start-value in a number style in my proposal.
> 
> I think the text:restart-at feature should be used instead.
> 
> === R6. Use case for ODF1.2 list-override enhancement ===
> 
> Oliver's/Thomas'/David's and Michael's proposal  meets this requirement.
> 


-- 
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: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering



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