Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3E7D8CF5B for ; Mon, 9 Jul 2012 15:25:49 +0000 (UTC) Received: (qmail 56743 invoked by uid 500); 9 Jul 2012 15:25:49 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 56598 invoked by uid 500); 9 Jul 2012 15:25:48 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 56548 invoked by uid 99); 9 Jul 2012 15:25:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2012 15:25:48 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of orwittmann@googlemail.com designates 209.85.214.47 as permitted sender) Received: from [209.85.214.47] (HELO mail-bk0-f47.google.com) (209.85.214.47) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2012 15:25:41 +0000 Received: by bkcik5 with SMTP id ik5so5887777bkc.6 for ; Mon, 09 Jul 2012 08:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=k4MeoEb+5OxcizP49+Dk9ABFhuM+DSgFe2R8Ipiekcs=; b=OeYuW2badLQ3WNhVAvYxg+IGWefbxnmg9SiBFSAzCY53T742lDJ8tHc4Qw17OLqQ6L 2IxAgGqz3fkz9U9LOoVwuTmnW8vuW9sU2hkvWipDrflTMpxyvc7TYBNmZOTeZasqAqtd P9XJGhEFCHUK6i+Z2veYq1dubmpj+0yFy2Wt+hWcYmVD8heJD3IRwUIeC3RYbuMa2nLP jKiwmfkUOI8Q4unUxb5j+snEGp71vI1574sksrKmkIKfBIyfFQkilnZ/OSam4WH5oxq2 1GAOKj5jeUK//Q8l3yDT0U1nDVcKIDB+uwmkUPXoBZ9NKhjoUgs/55Hb7EFZ3txhMv8S 3zLA== Received: by 10.204.156.69 with SMTP id v5mr8746202bkw.97.1341847521066; Mon, 09 Jul 2012 08:25:21 -0700 (PDT) Received: from [9.155.131.111] (deibp9eh1--blueice2n2.emea.ibm.com. [195.212.29.172]) by mx.google.com with ESMTPS id o4sm26559929bkv.15.2012.07.09.08.25.19 (version=SSLv3 cipher=OTHER); Mon, 09 Jul 2012 08:25:19 -0700 (PDT) Message-ID: <4FFAF7E1.9040402@googlemail.com> Date: Mon, 09 Jul 2012 17:25:21 +0200 From: Oliver-Rainer Wittmann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: ooo-dev@incubator.apache.org Subject: Re: [Review|Discussion]For Ideas and Comments on the Vision of Writer's Track Changes Improvement References: <008e01cd58d2$a315be20$e9413a60$@acm.org> <012701cd5939$fcc613e0$f6523ba0$@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, On 04.07.2012 04:41, chengjh wrote: > Hi Dennis,I appreciate your questions,they are significant areas we have to > take carefully.Thanks. > > On Wed, Jul 4, 2012 at 12:36 AM, Dennis E. Hamilton > wrote: > >> I have questions about the way that the improvements are intended to be >> extensions to the ODF format. >> >> I understand from what is said that improvements are introduced into the >> ODF document in a way that they will be ignored by older implementations >> and other implementations that are unaware of them. The intention is to >> map to and from .doc in a reliable manner. >> > > 1. How are the extensions introduced such that conforming ODF consumers >> will ignore them properly? Will users be able to turn off the improvements >> in order to produce conforming ODF documents? >> >> a)That's a good question.Because current ODF formats on Track Changes are > limited,that means only limited capabilities are able to be supported. In > order to achieve our goal to improve the fidelity with MS Word, we have to > extend Track Changes ODF formats and propose to OASIS ODF to become > standard at the end.Thus,the compatibility with previous releases will be a > challenging job.Our strategy is that the current import/export code logic > on Track Changes will be kept to ensure the same supported change records > defined in ODF 1.1/1.2 as before in our improved solution.If > possible,the extended > parts will be implemented with another code logic,not mixed, to ensure > these parts will not be recognized by previous releases. > > b)And also,it seems a good idea to provide an option item in > "Tools->Options...->Writer->Compatibility" to turn on/off the > improvements.Thanks. > This can be already handled in general. As mentioned in my presentation at OOoCon 2010 (especially slide 14ff) [1] we already have the ODF format version field. On this field we can depend our (not yet in ODF available) features//enhancements/improvements/... > >> 2. Will ignoring the extensions result in an usable conforming ODF >> document and will round-trip return to the producer of the extensions be >> tolerable. Should there be warning when an user makes changes that rely on >> the improvements in a document that was not produced by an >> improvement-aware implementation? >> > > c) We should avoid to generate un-usable ODF document,otherwise,the design > should have problem.. > d) I don't think it necessary to give warning message to end users when > saving changes records with our improvements..I think it better for an > application to enable a mechanism to provide warning message to end users > when identifying un-recognized info. > >> >> 3. How are the improvement extensions to the ODF format being made known >> so that other consumers of ODF can support them either partially or >> completely to provide a smoother experience in support of their users and >> in providing interoperability? >> > > e)Finally,our improvements on the ODF formats on Track Changes will be > proposed and taken as OASIS ODF standards. > In general I think we should align our change tracking enhancements with the work currently going on in the ODF TC regarding change tracking. The work in the ODF TC should more or less guide how we represent/express our change tracking enhancements in ODF. [1] http://people.apache.org/~orw/210-209-1-PB.pdf Best regards, Oliver. > >> >> -----Original Message----- >> From: chengjh [mailto:chengjh@apache.org] >> Sent: Tuesday, July 03, 2012 00:25 >> To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org >> Subject: Re: [Review|Discussion]For Ideas and Comments on the Vision of >> Writer's Track Changes Improvement >> >> Hi Dennis, >> >> Thanks for your feedback.Please say my a),b),c) and d). >> >> On Tue, Jul 3, 2012 at 12:16 PM, Dennis E. Hamilton < >> dennis.hamilton@acm.org >>> wrote: >> >> [ ... ] >> >>> Because of this, it is important to understand how your proposed Track >>> Changes Improvement will be reflect in the ODF 1.2 documents consumed and >>> produced by Apache OpenOffice at this time. That is, what needs to be >> done >>> in the format, if anything, and how is interoperable communication of >> that >>> handled in the persistent document? >>> >> >> b) One of the significant principles of the improvement is to keep >> compatibility >> >> http://wiki.services.openoffice.org/wiki/Writer/ToDo/TrackChanges#Design_Principles >> with >> previous releases of AOO/Symphony in order to ensure the persistent >> document. The new formats saved in the improvement will be lost when being >> launched into old versions' AOO/Symphony. >> >> [ ... ] >> >> > >