RE: [oic] RE: interop advisory - unsupported change tracking

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

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