Re: [office] JIRA issues for 21 December 2015

[Regina Henschel <regina.henschel@libreoffice.org>]

Hi all,

Patrick Durusau schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greetings!
>
> I have revised the spreadsheet to remove issues we processed this AM
> and have attached that revision for our meeting on 2015-21-12.
>
> Hope everyone is at the start of a great week!

some comments:


https://issues.oasis-open.org/browse/OFFICE-1253
The reporter does not request the page or line break itself, but he 
wants to get a page or line number that is stable, so that it can be 
used in citations. An additional attribute "value" for the number in the 
last rendering might help, or a readonly "archive" format for the whole 
file. But feature request should go to implementers first, so I agree 
with closing.

=================================================

https://issues.oasis-open.org/browse/OFFICE-1263
We have seen exact the same problem, when we decide to use svn for the 
specification documents. If Jos is willing to take it, he might identify 
possible changes/additions to the standard, that would be helpful for 
common Content Managemant Systems. Or Svante might take it and handle it 
together with change tracking.
The issue https://issues.oasis-open.org/browse/OFFICE-3788
“Make xml:ids stable over the lifetime of a document”
might be related. That issue has Patrick as assignee.
I think it is worth to consider, but it needs an assignee then. Only 
target ODF 1.3 is optimistic.

=================================================

https://issues.oasis-open.org/browse/OFFICE-1276
This issue is strong related to issue
https://issues.oasis-open.org/browse/OFFICE-3886
“Extend Open Document Specification to improve support for bibliographies.”
which has as assignee Thomas O'Reilly.
Therefore I suggest to close it as duplicate of OFFICE-3886 or the other 
way round. In addition we should ask Thomas, if he actually wants to 
work on issue OFFICE-3886, otherwise we need a new assignee, if it is 
intended to solve it for ODF1.3

=================================================

https://issues.oasis-open.org/browse/OFFICE-1277
There is a long discussion (19 mails!) in the thread
https://lists.oasis-open.org/archives/office-comment/200903/threads.html#00001
It needs a volunteer to sort this out.
Office-1306 is duplicate to this.
OFFICE-2409 and OFFICE-2599 are related.

There is no need for a common scripting language. LibreOffice and Apache 
OpenOffice have the ability to use several languages. The real problem 
is, that the scripting language works on the model, that the 
implementation uses. So LO/AOO have an own API, which not only addresses 
the document itself but the UI and information about the user too. Those 
parts cannot work for other implementations with their own models.

The document parts can be specified. ODF needs a common DOM, similar as 
it is defined for HTML. That it not depending on any implementation. 
Implementers, especially LO/AOO would need to map it to their API. 
Because a lot of macros exist, dropping the API of LO/AOO is no option.
Specifying a DOM would be a task for the TC, not for implementers. For 
to get more interoperability in macros, I think it need to be done. But 
it is a large task and do we have volunteers to bring it forward? It is 
too large to be done in spare time.

=================================================

https://issues.oasis-open.org/browse/OFFICE-1283
LibreOffice and Apache OpenOffice have this file type implemented. 
Therefore it should not be dropped, but specified. It belongs into 2.2.3 
OpenDocument Text Document

=================================================

https://issues.oasis-open.org/browse/OFFICE-1286
The issue is not about XForms but about an attribute of the <form:form> 
or <form:textarea> element or any of the other controls.
LibreOffice and Apache OpenOffice use this attribute. There is even an 
issue, that LO and AOO depend on it, although the attribute is optional.

The issue OFFICE-1286 seems to belong to 
http://tools.oasis-open.org/version-control/browse/wsvn/oic/Advisories/00003-form_control_fallback/trunk/description.html. 
The recommendation there has been implemented in ODF 1.2. The 
specification in '19.258 form:control-implementation' has the text "If 
the consumer supports the form element this attribute is used with, but 
does not support the specific concrete rendition or implementation, the 
consumer shall ignore the form:control-implementation attribute and use 
its own rendition of the form element."

I see no need to remove the attribute and suggest to close the issue.

=================================================

Kind regards
Regina