openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: OOXML
Date Sun, 03 Aug 2014 07:56:54 GMT
On 2 August 2014 22:31, Dennis E. Hamilton <dennis.hamilton@acm.org> wrote:

> 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).
>

Does a consumer normally have some sort of conformance sheet (like we have
for communication protocols) or is it solely the user that painfully finds
the lack of support ?


In the other mail you write a quite interesting note about digital signing
of artifact the user cannot see. Do you happen to know how microsoft goes
around that with the web based offerings ?

Thanks for some very interesting input.
rgds
jan I.

>
>
>  -- Dennis E. Hamilton
>     dennis.hamilton@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:jani@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.hamilton@acm.org>
> wrote:
>
> > <orcnote>s below.
> >
> >
> > -----Original Message-----
> > From: jan i [mailto:jani@apache.org]
> > Sent: Saturday, August 2, 2014 08:57
> > To: dev
> > Subject: Re: OOXML
> >
> > On 2 August 2014 17:06, Louis Suárez-Potts <luispo@gmail.com> wrote:
> >
> > >
> > > > On 2014-08-02, at 10:24, Alexandro Colorado <jza@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-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message