On 2 August 2014 22:31, Dennis E. Hamilton <dennis.hamil...@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.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 > >
