OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only

  • 1.  Agenda next meeting

    Posted 09-05-2024 13:54

    Hi all,

    I am currently collecting items for a presentation of TC activities for the upcoming LibreOffice Conference. Thereby I have noticed a few things that we should address in the TC:


    Agenda topics
    =============

    What is current state of ODF 1.3 at ISO?

    XLOOKUP https://issues.oasis-open.org/browse/OFFICE-4154
    accept the issue (i.e change Status to Open).
    No further action now. When I remember correctly, we decided to set "fix version" only for issues which are fixed and keep it empty until then.

    Update issues in JIRA according to TC decisions in calls
    Who should do it?
    The following issues are affected so far:

    2023-12-11 https://issues.oasis-open.org/browse/OFFICE_3787 
    decision was: close as duplicate of OFFICE-3768
    2023-12-11 https://issues.oasis-open.org/browse/OFFICE-3786
    decision was: close as duplicate of OFFICE-3768
    https://issues.oasis-open.org/browse/OFFICE-3768

    https://issues.oasis-open.org/browse/OFFICE-4094
    2023-10-09, 2023-10-16, 2023-10-23, 2023-10-30
    Resolution field "fixed" does not fit to current state. We had removed it from ODF 1.4 and restored the text from ODF 1.3 for ODF 1.4. Resolution should be "unresolved" and the "fix version" should be empty, as it is not fixed yet. Comment from MS team is pending.

    https://issues.oasis-open.org/browse/OFFICE-4128
    The status is correct, but the Resolution text box is empty.

    https://issues.oasis-open.org/browse/OFFICE-4147
    2023-10-09, 2023-10-16, 2023-10-23
    We agreed on the proposal, Resolution field should be "Fixed" and Resolution text box should contain the resolution.

    https://issues.oasis-open.org/browse/OFFICE-4149
    Was editorial. Nevertheless, resolution field should be "Applied".

    https://issues.oasis-open.org/browse/OFFICE-4152
    2023-12-04, 2023-12-11
    Resolution field should be "fixed", Resolution text box should contain the resolution.

    Kind regards,

    Regina



    ------------------------------
    Regina Henschel
    The Document Foundation
    Dortmund
    ------------------------------


  • 2.  RE: Agenda next meeting

    Posted 09-09-2024 16:11
    Hi Regina and all

    I have been looking at the JIRA issues for which Regina has pointed out
    that they have not been updated since decisions were taken by the TC.
    Here are my first observations, which all relate to OFFICE-3768,
    OFFICE-3786 and OFFICE-3787.

    As far as I can see, these issues all deal with slightly different
    aspects of the problem term "empty cell", but I agree that they deal
    with essentially the same issue and should therefore be merged.

    OFFICE-3768 points out that "empty cell" is ambiguous, because of
    potential confusion between "empty cell" and "empty string". The
    commentary suggests that changing "empty cell" to "blank cell" would be
    an improvement on the proposal ("unassigned cell"), as it aligns the
    terminology used with the function named ISBLANK. Patrick lists some,
    but I think not all, of the affected subsections, including 19.686: see
    OFFICE-3786. However, the term "empty" applied to a cell cannot be
    replaced with "blank" in at least two function descriptions, 6.13.8
    COUNTBLANK and 6.13.14 ISBLANK, as this would create circular
    statements: "a cell is blank if it is blank...".

    OFFICE-3786 points out that a consistent definition of "empty cell"
    should be used in all Parts, and mentions the issue with respect to Part
    3, 19.686 table:operator. This is a separate issue to OFFICE-3768, as
    presumably "blank cell" should ideally be defined for the same reasons
    that "empty cell" might otherwise be defined.

    OFFICE-3787 lists the subsections that Patrick spotted when commenting
    on OFFICE-3768: 6.3.5 Conversion to Number; 6.3.15 Conversion to
    DateParam; 6.3.16 Conversion to TimeParam. Patrick also mentions that
    6.13.8 COUNTBLANK and 6.13.14 ISBLANK will be the subject of a separate
    issue, but I see no evidence of a separate JIRA issue for these last two.

    I therefore agree with Regina that it makes sense to merge OFFICE-3768,
    OFFICE-3786 and OFFICE-3787 into a single issue, and OFFICE-3768 is as
    good a choice as any for which issue to leave open. The issue of whether
    or not the descriptions of COUNTBLANK and ISBLANK should be altered can
    be added to the same merged issue.

    But I think it would be helpful for there to be a brief discussion
    before we merge the issues, to make sure that I've not overlooked an
    aspect of this.

    Francis


    Original Message


  • 3.  RE: Agenda next meeting

    Posted 09-10-2024 03:09
    I've now updated the other issues listed by Regina, so all should now
    have the correct status and text in the Resolution field. Please advise
    me if you see anything that isn't correct.

    Francis


    Original Message


Related Content