Re: [office-collab] Re: [office] Groups - MCT Challenge #2 (PDF) uploaded

[Svante Schubert <svante.schubert@gmail.com>]

Hello Andreas,

I agree with you that we should consider to focus ourselves first on
basic operations.
It is better to specify basics operations first and expand these, so we
have something to deliver ASAP.

The complex operations as "merge paragraph" are nice to have as if we
could find a common denominator of behavior, we would be able to save a
lot of verbose operations (convention over configuration).
The conclusion that everyone have to follow the common denominator is
incorrect, as ODF applications that behave different are able to use the
mergeParagraph operation and add their delta via basic operations to the
common merge operation.
Finding the deltas helps us IMHO to get a view on the required basic
operations.

On 05.12.2012 20:27, Andreas J Guelzow wrote:
> I have not been attending the last collab calls since the discussion has
> been side-tracked (in my opinion) to talk about implementation
> behaviour, although it is in principle impossible to know the interface
> users are facing to modify the document (unless of course the interface
> is forced by the standard).
The interface like character selection and delete/backspace handling to
provide a hint of the desired user change.
No normalization of interface nor a normalization of change was
intended. The goal - as described above - was to find the common change
information (denominator)
>
> Since ODF is a document format, it really should be mood about the
> choices made by implementors and allow a wide variety of interfaces,
> including those possibly not envisioned yet.
Sure.
>
> What I think should be provided is a basic set of actions that modify
> the document (possibly with the possibility to optionally group those
> actions) so that any user-action permissible inside a specific interface
> can be translated into a sequence of these base actions.
Agree to focus on basics first. Still believe that if we neglect complex
operations (like a pattern/macro/batch of basic operations) as the move
of a row, which could be expressed as well by add and delete cells only,
we would provide implementations with some overhead and loose some
elegance. But I am with you to add the bells and whistles afterwards.
>
> How exactly a certain implementation combines the styles and formattings
> of two paragraphs that are being fused in to a single paragraph really
> should not have any bearing on the stored change-track actions (unless
> one of course wants to force all implementations to have the identical
> behaviour.)
As stated, with having a common denominator others are free to add their
delta to it and still save operations overhead.
No, restrictions given or intended.

PS: Please feel free to state your concerns right away on the list. No
need to wait 14 days if you think we are heading in a wrong directions.
Nevertheless I am glad about your feed-back and it has some truth in it
IMHO (to focus on basics first).

Thanks and a nice St Nicholas' Day,
Svante
> Andreas 
>
> On Wed, 2012-12-05 at 11:21 -0700, Dennis E. Hamilton wrote:
>> Let me clean up my aside about what can be known:
>>
>> I mean that the MCT cannot govern producer behavior about what happened that led up to the produced change-tracking.  Users may have their own requirements on what producers and consumers are acceptable for their work, but there is no way to reflect that in conformance clauses for MCT, especially for producers.
>>
>> Am I mistaken in this?
>>
>> -----Original Message-----
>> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
>> Sent: Wednesday, December 05, 2012 10:18
>> To: 'Svante Schubert'; 'office-collab@lists.oasis-open.org'
>> Subject: RE: [office-collab] Re: [office] Groups - MCT Challenge #2 (PDF) uploaded
>>
>> OK, good.
>>
>> Now, is there a technical definition of measurable equivalence?  The one about deletion of a string of characters one at a time being tracked that way (but the preference is to track it as one change) is easy.  
>>
>> When there are non-coalescing atomic actions, there is the matter of different cases, as already discussed for insertion in insertions, deletions across deletions, etc., that can arrive in more than one way but aren't *necessarily* reflected in the persistent document.
>>
>>   Or perhaps that is simply up to the producer, since there is no way to know that the user actually did it as one action once the document is produced?  (I may have answered my own question, assuming the MCT specification does not constrain the relationship of the producer to its provisions for in-session editing actions.  I am assuming that such a constraint is inappropriate in a format specification, since there's no way to know.)  
>>
>>  - Dennis
>>
>> -----Original Message-----
>> From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Svante Schubert
>> Sent: Wednesday, December 05, 2012 09:40
>> To: office-collab@lists.oasis-open.org
>> Subject: Re: [office-collab] Re: [office] Groups - MCT Challenge #2 (PDF) uploaded
>>
>> On 05.12.2012 18:19, Dennis E. Hamilton wrote:
>>> My sympathies are with the statement by Oliver on the call log:
>>>
>>>    [16:08] Oliver-Rainer Wittmann: Thus, yes I agree. I would 
>>>    also go a step further: Would be good, if an application 
>>>    could indicate a certain bundling and may be also name it.
>>>
>> [ ... ]
>> I believe you you refer to the log, the original quote was '
>>
>> the information set of changes have to be the same.
>>
>> ' It was meant that the granularity of changes does not matter. It only
>> matters that the overall change is the same. Accepting/Rejecting once
>> "abc" or each three separated characters is up to the application.
>> Operations used by applications to express the change have to be equivalent.
>>>  - Dennis
>>>
>> [...]
>>
>> Best regards,
>> Svante
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: office-collab-help@lists.oasis-open.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: office-collab-help@lists.oasis-open.org
>>