Below, Jan asks
"Does the standard contain some rules about keeping private information ?"
There are two cases for ODF 1.2.
First there is the case for foreign elements/attributes/attribute values. This
would be the case for some sort of extended material incorporated in the ODF
document. This makes a Conforming OpenDocument Document into an Extended
OpenDocument Document. A Conforming OpenDocument Consumer is permitted to
ignore all of that, based on some rules about whether or not it occurs in
(technically-defined) paragraph content or elsewhere in the format. There can
also be foreign content in the XML package of the document, where there is no
recognized relationship of that content to anything in the document as seen by
an ODF Consumer.
There are places where the preservation of such foreign material is recommended
but not required. Most implementations lose all content that they are not
implemented to interpret. Microsoft Office very definitely does that in its
acceptance of OpenDocument Document files. This happens mainly because the
typical internal model doesn't preserve the original XML parts and it doesn't
work by manipulation of the XML parts. I suspect that Microsoft concerns about
document security are also a factor, in addition to unwillingness to support
features that are not part of the ODF specification. (The position, as I
understand it, is that they will support the standard, not OpenOffice's
particular implementation around it, and I don't know how much flexibility
there is in that respect. That OpenOffice *is* the standard is a popular view
that happens to be inconsistent with the principles of ISO or any
standards-development organization that are committed to the ideal of
independently-implemented interoperable implementations.)
The second case has to do with features of ODF that a particular implementation
does not support. In general, these do not survive in current implementations,
since import into the internal model loses that material and there is
consequently no provision for exporting it. Here, there is the fact that there
is no strict minimum Conforming OpenDocument Consumer. A consumer must not
object to anything in the document file that conforms to the ODF specification,
but it is not required to "interpret" all or even any minimum set of features.
There is no producer that I am aware of that produces all features provided for
in the ODF specification, and most implementations only interpret those
features that they are designed to produce (sometimes incorrectly) themselves.
This doesn't matter too much if you use implementations with a common
genealogy, but across independent implementations not having any common code
base there tend to be unexpected surprises. There are also many places where a
provision of ODF is not rigorously defined and implementation-dependent
variation is the result, whether explicitly called out (e.g., for macros and
scripts) or not (e.g., for supported image formats).
-- Dennis E. Hamilton
dennis.hamil...@acm.org +1-206-779-9430
https://keybase.io/orcmid PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail
-----Original Message-----
From: jan i [mailto:j...@apache.org]
Sent: Saturday, August 2, 2014 11:58
To: dev; Dennis Hamilton
Subject: Re: OOXML
On 2 August 2014 20:27, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote:
> <orcnote>s below.
>
>
> -----Original Message-----
> From: jan i [mailto:j...@apache.org]
> Sent: Saturday, August 2, 2014 08:57
> To: dev
> Subject: Re: OOXML
>
> On 2 August 2014 17:06, Louis Suárez-Potts <lui...@gmail.com> wrote:
>
> >
> > > On 2014-08-02, at 10:24, Alexandro Colorado <j...@oooes.org> wrote:
> > >
> > > The Support that is done is to receieve OOXML not to produce them, the
> > > discussion issue would be to support legacy formats like .doc or .xls.
> > >
> > > I still dont see a point to generate OOXML and most people dont care
> > > as long as they can send in office native formats.
> > >
> > > I never heard someone saying, please send it on docx, your doc is a
> > > closed binary format.
> >
> > Actually, I have. But it also matters on mobile, as well as, I'd guess,
> > for some developing processes for batch conversion of documents. Finally,
> > it's not evident to me that refusing to develop to what is likely to
> become
> > the major desktop document format globally—alas—is a good strategy that
> > would lead to the adoption of OO. Rather, it seems it would only help
> those
> > applications that do (express) both ODF *and* .docx well.
> >
>
> Please dont forget, the computer business have always had 2 types of
> standard the official one and the de facto one.
>
> For those to young to remember, tcp/ip is not an official standard (OSI
> was) but something a number of companies decided to promote, I see docx in
> the same light.
>
> <orcnote>
> I think this has it backwards. For ages, .doc was the defacto standard
> And de jure ISO/W3C standards like SGML, ODA, and even XML did not do
> Anything to dent that. That is now .doc and .docx, however defacto
> you consider them to be (although they are both now all open formats).
>
> I am squarely in the same camp as Peter Kelley and Luis Suarez-
> Potts with regard to the pragmatic situation that exists. One-way
> movement to ODF is simply going to be unacceptable, possibly forever,
> if you are determined to have "there must be only one" in a niche of
> like-minded followers.
>
> This is unfortunate for one particular reason -- ODF is the only well-
> established multi-platform document format, thanks to the wider platform
> support of LibreOffice and Apache OpenOffice. (Those also introduce
> de facto and monoculture factors that are omitted in the marketing
> speak.)
>
> But without a dramatic increase in Linux penetration, this may not dent
> The state of affairs much. The bigger penetration opportunity is iOS
> and Android, not Linux. And you may have noticed that Microsoft has
> figured that out and is moving dramatically to provide OOXML inter-
> operability via the cloud (especially Sky-/One-Drive and Office Web
> Apps) and via phone/phablet/tablet presence on Windows 8, WindowsPhone8,
> Android (including the Amazon flavor), and iOS. There are even
> provisions for concurrent collaboration already strong in the flag-
> carrying application, Microsoft OneNote, an openly-documented but
> not-standardized format.
>
> The last time I checked, the OneDrive free in-browser Office Web Apps
> also support ODF 1.2 documents, although it will convert them to a
> MSO-compatible cloud subset form if you want to edit them there, even
> Though retrievable in ODF 1.2. Viewing works out of the box. My
> impression of the editing pre-conversion is that is a safety measure
> in case any ODF feature loss is unacceptable and so you still have an
> intact original there.
> </orcmid>
>
I too am on peter fast rolling waggon :-) but I am also confused.
@peter maybe you could explain a couple of things, for non-document
specialists:
1) Following your thought, with biderectional editors. Why would a editor
have a home format ?
Following your thought to the end, the editor would always save/read in the
format, and things not supported in the format with be saved as private.
2) When editing in format foo, one can expect that not all features are
supported (like e.g. microsoft macros), these are handled as private
containers.
But looking at LO there seems to be huge challenges when doing especially
copy/paste operations ?
3) If we save private info in .docx, how can be be sure that a microsoft
editor does not destroy it ?
Does the standard contain some rules about keeping private information ?
thanks in advance
jan I.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
