[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [oic] RE: interop advisory - unsupported change tracking
I am not looking at the advisory, but I want to respond to this question at once: "Do you also need to explicitly say that a Consumer that does not support track changes should not lose the element if the file is saved in that application?" <soapbox> My view is that a Producer that does not support track changes should never include any track change material in its output. The changed material that is retained at the front of the text is linked to from markers in the main text stream. A producer that has found these markers in a consumed document must delete these if it doesn't support them (probably simply ignoring them) since it has no idea what the interdependencies are and is probably not prepared to preserve the connecting xml:id values that are involved, etc. The only safe thing to do is to remove the not-understood, unsupported material lest the result actually be a corruption. And, if the non-supporting producer manipulated a consumed document before saving it, the progression of change history has been broken and we have no idea how this should have led to change tracking adjustments. This safe practice will have the produced document be as if all tracked changes had been accepted. That is in effect all that producer can do, since it doesn't know how to reverse a change. And since it can't properly maintain the change-tracked history, it is unwise to assume a downstream consumer could figure it out. Also, a producer that is unaware of what these are has a very difficult time offering its user an opportunity to sign the produced document unless the changes are effectively all accepted (the consequence of ignoring the history) and it is the clean document that is being signed. Finally, the preservation of detached but erstwhile previous-information and change history material is a means for establishing a covert channel and purloining private information. Not a great way of doing this, but it is important to shrink the surface against which exploits might be attempted and then have to be protected against. Coming back to the consumer. Since a non-supporting consumer cannot show the tracked changes and doesn't even have a way to turn their visibility on or off and their recording on or off, the document will appear as if there are no tracked changes. Any produced result should certainly be consistent with that. (Of course, there is no effect on the original consumed document file.) </soapbox> - Dennis - - - - - - - - - - - Ain't Signin' No Stinkin' Blank Checks No More No Way No How Honor Pledge of the Interoperability Warriors -----Original Message----- From: Cherie Ekholm [mailto:cheriee@exchange.microsoft.com] Sent: Thursday, June 10, 2010 00:18 To: Hanssens Bart; oic@lists.oasis-open.org Subject: [oic] RE: interop advisory, example [ ... ] On the example advisory: Do you also need to explicitly say that a Consumer that does not support track changes should not lose the element if the file is saved in that application? -----Original Message----- From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] Sent: Wednesday, June 09, 2010 10:50 PM To: oic@lists.oasis-open.org Subject: [oic] RE: interop advisory, example Hi, any comments so far ? I'd really like to nail this down before the next call :-) Thanks Bart ________________________________________ From: Hanssens Bart [Bart.Hanssens@fedict.be] Sent: Friday, June 04, 2010 7:49 PM To: oic@lists.oasis-open.org Subject: [oic] interop advisory, example Hi, as discussed during the last TC call, I've created an example on how I think an Interop Advisory could look like: http://wiki.oasis-open.org/oic/InteropAdvisories I've also added a suggestion for a workflow. Keywords: - practical - focused - fast consensus Even if the proposed advisory turns out to be an implementation bug, it might still be useful for creating an ODF test suite (or as input for the next State of Interop report) Best regards Bart --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]