Groups - 18-10-08-spec00032 uploaded

[Patrick Durusau<patrick@durusau.net>]

        Submitter's message
        Greetings!

The next draft of ODF part 3, Documents. It includes the following edits:

Suggested by Francis Cave:


> Open Document Drawing Document 2.2.5 Office-3744
>
> The status of Office-3744 appears to be "Unresolved". Is this correct? There's a comment from Regina Henschel that this issue has the wrong status.
>
> Also, it isn't clear from Office-3744 what is to be corrected. Office-3746 suggests that the correction is to remove "." following "application/" in the MIME type. There's nothing in JIRA that suggests that the 's' should be inserted following 'graphic' in 'graphic-template'.
>

Ah, the mime types listed in Appendix C uses the plural form, "graphics" so this change is conforming to that definition.

> Open Document Drawing Document 2.2.5 Office-3746
>
> There's nothing in JIRA that suggests that the 's' should be inserted following 'graphic' in 'graphic-template'. See above.
>
>
Yes, well, unfortunately you have to follow the issue link (a bad practice from years ago) to discover the reference to appendix C:

http://lists.oasis-open.org/archives/office-comment/201202/msg00000.html


> New text: Change Tracking General Office-3873
>
> We have already discussed this and I believe you are drafting some new text.
>

Text agreed to by TC on 10 Sept. 2018 (and now in latest draft):

"The under-specification of change tracking in ODF 1.2 resulted in varying implementations of this feature. Where interoperability between implementations is required, this feature should be checked for interoperability."

> List Item Style Rules 5.3.5 Office-3782
>
> The text appears to have been changed in accordance with the agreed Resolution, although the tracked change is slightly muddled in WD10. Might be worth double-checking this one.
>

You don't find "If the list is not contained in (surrounded by) another list or no list level style is defined by any of the list styles assigned to the surrounding lists, the list level style defined by the default list style is used." a model of clarity? ;-)

I think the intent was to deal with surrounding lists that could have list styles defined and inherited by the contained list. But, that is defined in the bullet point just before this one so perhaps:

"If a list is not contained in (surrounded by) another list or does not have an assigned list level style, the list level style defined by the default list style is used." (I have inserted this in the text. Should the TC object, we can always change it back.)

5.3.6 Office-1437
>
> The agreed Resolution states that the new paragraph is to be inserted after the first Note, but it has been inserted after the heading. Is this intentional? In all other respects, the text has been changed in accordance with the agreed Resolution.
>
My bad, fixed to follow the Note.


>
> 11.3 Office-3928
>
> It is not entirely clear in JIRA what Resolution was finally agreed for this new section. The last two short paragraphs and the coded example (omitted and covered by a comment in WD10) are not documented anywhere in JIRA that I can see. The text of the first four paragraphs appear to be what was agreed.
>
Context for the JIRA discussion was: https://wiki.oasis-open.org/office/ProposalCoordinateRegion

Does that help?


> 14.4 Office-3776
>
> The new section has been inserted in accordance with the agreed Resolution, except that it includes 'an annotation' instead of 'the annotation'.
>

Question: Should we use the definite article here? To me, "an annotation" says applies to any annotation. To say, "the annotation" implies we have some specific annotation in mind. Yes?

> 16.2 Office-3935
>
> The text has been changed in accordance with the agreed Resolution.
>
> NOTE: This change in Appendix G.2 incorrectly links to 16.4.
>

Done.

>
> 16.11 Office-3789
>
> There appears to be an extra first paragraph of new text that in part (first sentence) duplicates the second paragraph. The text of the second paragraph accords with the agreed Resolution.
>
No, differs because first sentence depends on absence of element. But, agree it is poorly worded. Changing from:

*****

The element represents the content for a header for a first page, if different from the left/right page in a element.

The element represents the content for a header for a first page. Hereby the term "first page"
*****

to:

*****

The element represents the content for a header for a first page, if different from the left/right page in a element.

The term "first page"...
*****

subject to approval by the TC.



> 16.13 Office-3789
>
> There appears to be an extra first paragraph of new text that in part (first sentence) duplicates the second paragraph. The text of the second paragraph accords with the agreed Resolution.
>

From:

*****

The element represents the content for a footer for a first page, if different from the left/right page in a element.

The element represents the content for a footer for a first page. Hereby the term "first page" means
*****

to:

*****

The element represents the content for a footer for a first page, if different from the left/right page in a element.

The term "first page" ...
*****

subject to approval by the TC.


> General 16.29.1 Office-3765
>
> The text has been changed in accordance with the agreed Resolution.
>
> NOTE: I don't see this change in the list of changes in Appendix G.2.
>
Done. Create target, inserted ref.


> 16.29.2 Office-3765
>
> This element is listed in Appendix G.2 as having changed text, but there is no change to the text, and nor is the element changed by the agreed Resolution.
>
Corrected.

> 16.29.3 Office-3860
>
> The text has been changed in accordance with the agreed Resolution. However, the change appears to be in text that is generated automatically from the schema, so I'm not sure that a manual change is appropriate.
>
Mistake but all manual changes in the schema sections will be deleted in the final stages of generating the text.

A good reminder that I need to start working on the scripts we need for that task.


>
> 16.29.7 Office-3695
>
> In Appendix G.2 this change is incorrectly linked to section 16.8.
>
> The text has been changed in accordance with the agreed Resolution. However, the change appears to be in text that is generated automatically from the schema, so I'm not sure that a manual change is appropriate.
>

Mistake but will be stripped in the final production anyway.

*********

> 16.29.8 Office-3765
>
> This element is listed in Appendix G.2 as having changed text, but there is no change to the text, and nor is the element changed by the agreed Resolution.
>

> 16.29.10 Office-3765
>
> This element is listed in Appendix G.2 as having changed text, but there is no change to the text, and nor is the element changed by the agreed Resolution.
>

>
> 16.29.19 Office-3765
>
> This element is listed in Appendix G.2 as having changed text, but there is no change to the text, and nor is the element changed by the agreed Resolution.
>
> 16.29.26 Office-3765
>
> This element is listed in Appendix G.2 as having changed text, but there is no change to the text, and nor is the element changed by the agreed Resolution.
>
>

All of these are impacted by the element (new) but won't appear in the text until it is re-generated.

**********

> 16.42.6 Office-3933
>
> The text has been changed in accordance with the agreed Resolution, except that the word 'either' has not been inserted before 'a link' in the first sentence. This may be intentional, as 'either' is incorrect in this position. However, it might be clearer to put 'either' before 'specifies' than to omit it.
>
> NOTE: In the second sentence the phrase 'in case the document is represented as a package' is unclear. This should be looked at later when we read the text for sense: 'in case' could mean either 'in the case that' or 'just in case' - probably the former, but it could be expressed more clearly.
>

Done and agree with reading for sense comment.


> 16.42.9 Office-3742
>
> The text that has been inserted in the wrong section. According to the agreed Resolution, it should have been inserted in section 19.218.5. It doesn't make sense where it is.
>
>

Yes, and did insert part 2 of that issue as:

draw:style 19.218.5 of 16.42.9 Office-3742


> 17.25 Office-3937
>
> The text has been changed in accordance with the agreed Resolution.
>
> QUERY: Should the word 'element' be inserted at the end of the revised text, following ?
>
>
Yes, done and done.



> draw:formula 19.171 Office-3823
>
> The text has been changed in accordance with the agreed Resolution.
>
> NOTE: There appear to be changes in 19.171 Table 11 that don't related to either Office-3822 or Office-3823. Which issue Resolution is associated with these changes?
>
>
For hasfill and hasstroke, that would be https://issues.oasis-open.org/browse/OFFICE-2467 but that was done in ODF 1.2.

I checked the PDF for ODF 1.2 and the text we see as changed is present. Artifact of our applications?


> draw:transform 19.228 Office-3755
>
> The text has been changed in accordance with the agreed Resolution.
>
> NOTE: The change in Appendix G.2 links incorrectly to 19.438.
>
Corrected.


> draw:z-index 19.231 Office-2122
>
> The text has been changed in accordance with the agreed Resolution, except that there are no section links for the elements and .
>
>
I've changed this one but have I been inconsistent in the use of section links? Worried now that the draft may have other such instances. Need to sweep for those.


> number:forced-exponent-sign 19.349 Office-3860
>
> The attribute has been added in accordance with the agreed Resolution.
>
> NOTE: This new attribute is incorrectly linked to 16.29.6 in Appendix G.2.
>

Done.
> number:max-denominator-value 19.352 of 16.29.7 Office-3695
>
> The attribute has been added in accordance with the agreed Resolution.
>
> NOTE: In the first sentence of the second Note '1- or 2-digit denominator' would possibly be more correct grammatically than '1 or 2 digit denominator'.
>

Done.

> number:min-decimal-places 19.356 Office-3860
>
> The attribute has been added in accordance with the agreed Resolution.
>
> NOTE: This new attribute is listed twice in Appendix G.2: following chart:regression-name and following number:max-denominator-value.
>

First listing deleted.

>
> style:condition 19.472 Office-3882
>
> The text has been changed in accordance with the agreed Resolution.
>
> NOTE: The heading of Table 16 Host Dependent Properties has two spaces following 'Table 16'. I also notice that Table 15 doesn't follow the style for all Tables up to that point which is to follow the Table number with a spaced hyphen.
>
> NOTE: The change is listed twice in Appendix G.2.
>

Deleted the shorter listing.

Headings repaired.


> svg:height 19.543.4 of 10.5.2 Office-3932
>
> The text has been changed in accordance with the agreed Resolution, except that '' should be ''.
>
>

Done.

> text:list-id 19.835 Office-1437
>
> The text has been changed in accordance with the agreed Resolution.
>
> NOTE: The change in Appendix G.2 incorrectly links to 5.3.1.
>

Done.


>
> chart:data-label-series 20.9 Office-2117
>
> The new section appears to contain more text than is proposed in http://wiki.oasis-open.org/office/data-label-series_attributes. No agreed Resolution appears Office-2117. Specifically, the final paragraph is not mentioned anywhere.
>

The first reference I found was: https://issues.oasis-open.org/browse/OFFICE-3956 which appears to be quoting an email from Regina

http://lists.oasis-open.org/archives/office/201806/msg00005.html


> chart:interpolation 20.27 Office-3692
>
> I have not been able to check this change as I haven't been able to retrieve a copy of the agreed Resolution.
>
>
That is here: https://www.oasis-open.org/apps/org/workgroup/office/email/archives/201009/msg00819.html


> chart:regression-type 20.47 Office-3958
>
> The text has been changed in accordance with the agreed Resolution.
>
> NOTE: chart:regression-type is incorrectly listed in Annex G.2 as a changed element. It is a changed attribute.
>
Done.

>
> presentation:display-date-time 20.230 Office-3931
>
> The text has been changed in accordance with the agreed Resolution, except that a comma has been omitted between 'element' and 'where'.
>
Done.


> presentation:display-date-number 20.233 Office-3931
>
> The text has been changed in accordance with the agreed Resolution, except that at the end of the first paragraph 'pagenumber..' should be 'page-number.', i.e. a hyphen is missing and an extra period has been inserted.
>
Done.


> style:page-number 20.235 of 17.6 and 17.15 Office-3923
>
> The text has been changed in accordance with the agreed Resolution.
>
> NOTE: The change in Appendix G.2 links to the wrong sections for style:page-number and .
>

Done.


> style:contextual-spacing 20.252 Office-3767
>
> The attribute has been added in accordance with the agreed Resolution.
>
> NOTE: The text here contains two ways of styling the boolean values true and false. In the first case the value true is in quotation marks, but in the second case the value false is not in quotation marks. This looks inconsistent. Something worth checking more generally?
>

Yes, true is an attribute value for which we have a defined style. It should never appear with quote marks. (my bad)

> style:run-through 20.348 Office-2122
>
> The text has been changed in accordance with the agreed Resolution.
>
> NOTE: The deletion of the second paragraph does not appear to have been the result of an issue Resolution, but makes sense. Was this simply an editorial decision?
>
Editorial, to avoid repetition.


>
> style:scale-to-Y 20.352 Office-3857
>
> The attribute has been added in accordance with the agreed Resolution.
>
> NOTE: According to the agreed Resolution there should also be changes to 17.2 , 20.344 style:scale-to and 20.345 style:scale-to-pages (actually the Resolution states 'style:scale-to-page', without the 's' at the end, but I believe this is a typo). Of these I believe that 20.344 and 20.345 need manual changes to the text, but 17.2 only needs a change in text generated from the schema.
>
>

I think you mean in current numbering 20.351 and 20.352. Both appear to have the inserted text. The language:

*****
The style:scale-to-X attribute is usable with the following element: .
The style:scale-to-X attribute has the data type positiveInteger.
*****

Changed to Y as appropriate, is part of the auto-generated text.

Yes?

> text:anchor-type (graphic property) 20.415 Office-3945
>
> The text has been changed in accordance with Proposals A and C of the agreed Resolution, except that the first occurrence of 'frame' in the first paragraph has NOT been changed to 'drawing shape' as in Proposal A. Table 24 has been changed in accordance with Proposal D.
>
Done.

Suggested by Patrick Durusau
Styles General change entered but not listed in appendix E https://issues.oasis-open.org/browse/OFFICE-3697 - set target and entered in appendix E (also removed inline reference to JIRA issue)

2.2.3 OpenDocument Text Document https://issues.oasis-open.org/browse/OFFICE-2580 - change added to appendix E

10.4.7 https://issues.oasis-open.org/browse/OFFICE-2044 - corrected and added to appendix E

11.4 https://issues.oasis-open.org/browse/OFFICE-3883 - added to appendix E

19.191 draw:mime-type https://issues.oasis-open.org/browse/OFFICE-3943 - added to appendix E

19.543.2 svg:height - https://issues.oasis-open.org/browse/OFFICE-3883 - added to text and to appendix E

19.575.4 svg:width - https://issues.oasis-open.org/browse/OFFICE-3883 - added to text and to appendix E

20.103 draw:color-invesion 256 -> 255 https://issues.oasis-open.org/browse/OFFICE-3827 - added to appendix E

Appendix C Registered MIME types - odi deprecated - https://issues.oasis-open.org/browse/OFFICE-2002

Appendix C Registered MIME types - odt deprecated - https://issues.oasis-open.org/browse/OFFICE-2002


Edit based on these notes from the chat log:

Minutes from Open Document Format TC chat notes 2016-02-22

reflect:

*****

Patrick: https://issues.oasis-open.org/browse/OFFICE-2002
Michael Stahl: supported in OOo/AOO/LO is ODG and OTG
Regina Henschel: odi and oti is not supported in LO or AOO
Patrick: odi perhaps legacy from StarOffice format that was dropped
when OpenOffice appeared
Regina Henschel: Proposal: Deprecate odi and oti in ODF 1.3
Patrick: consent to deprecate odi and oti in ODF 1.3
*****

Not reflected in JIRA https://issues.oasis-open.org/browse/OFFICE-2002
or in part 3, Appendix C, non-normative mime types.

Suggest updating JIRA, applying the issue in the next draft.

*****

We are not quite at the point where outside review will be helpful. There is a lot of formatting, etc., to be cleaned up before asking you to spend time with the text.

We are making steady progress!

Hope everyone is at the start of a great week!

Patrick


-- Patrick Durusau

Document Name: 18-10-08-spec00032

---

Description
The first stage of COSM sponsored work on ODF part 3, Documents.
Download Latest Revision
Public Download Link

---

Submitter: Patrick Durusau
Group: OASIS Open Document Format for Office Applications (OpenDocument) TC
Folder: Committee Draft Feedback
Date submitted: 2018-10-08 15:49:46