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
---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php