Well for floating images I’d say there is a difference between it being anchored AT a position of being counted as a character. I say this because in Calligra such anchors were until recently implemented as a non printing character, with the downside of having to press cursor key twice to get past it. From: Svante Schubert [mailto:svante.schubert@gmail.com]
Sent: 15. januar 2016 18:45
To: C. Boemann <cbo@boemann.dk>
Cc: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Immutable Change Tracking Sorry, my phone sent the mail before I was finished, I will add the latter part now: On Thu, Jan 14, 2016 at 8:43 AM, Svante Schubert <svante.schubert@gmail.com> wrote:
On Jan 13, 2016 1:18 PM, "Camilla Boemann" <cbo@boemann.dk> wrote:
>
> Hi - long time no write
>
>
Nice to have you back!
>
> What Svante just said has my 100% backing
>
>
Always good to read this! ;)
>
> But I just realized that say 3rd character might not be good enough - because what about control characters – I’d say we shouldn’t count those in general, but our spec should probably specify that fact, The counting of characters is abstracted from the XML, for instance ODF whitespace handling is applied. Counting of characters is rather equivalent to cursor traveling as our need is to open up a span to select the characters we like to modify unambiguously. and maybe even specify if say an inline image is counted as a character (I think it should be),
It is indeed counted equivalent as an character. Nevertheless even an image floating somewhere, was by Open-XChange referenced by its position in the XML. but what about a pagenumber ref (one character or as many as the number takes up when printed – again I’d say one which makes the most sense) – I think we will agree an most if not all of the cases, but for a spec to be foolproof we better specify each and every possible case specifically)
>
There was a lot of discussion if a field is just metadata on the text or a construct for 3rd party content. In the end it ease the handling for the developer, if it is seen as an own component, which contains other components (such as text). >
>
> As to never ever change the original (not even on apply) – I am not so sure – we would deprecate the odf spec in that case, as all documents should then better start at an empty document with only changes recorded - on the other hand if we allow changes to be burned into xml then merging documents becomes a bit more problematic.
>
Only because the content is immutable, does not mean that changes can not be merged in the document view. Like showing the comments on the immutable contract similar to an additional layer. Even all steps of document history can be shown without changing the serialized document model. The immutable change tracking is for all scenarios possible, but I wonder if applications would go so far to do so.. But if there is demand, there is a market.. >
>
> Best regards
>
> Camilla
>
>
>
> From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Svante Schubert
> Sent: 13. januar 2016 12:56
> To: Patrick Durusau <patrick@durusau.net>
> Cc: office-collab@lists.oasis-open.org
> Subject: Re: [office-collab] Immutable Change Tracking
>
>
>
> The immutable change-tracking is indeed very useful for the scenario of commenting and editing a signed document. In this scenario the XML can not be changed, as otherwise the sign would be broken.
> Every comment/edit would be saved aside the signed content XML and might be signed again for each author, ensuring the validity of the complete content.
>
> That the changes will in the future refer to the position of change into the content instead of embedding it as prior we agree on. XPath is just a possible choice of implementation for referencing. From my observation Patrick's ideas are not based on XPath, he just took it as example. I rather would avoid XPath as ODF application do not require to have an XML model representation at run time, in contrary to the file model related DOM run-time API of browsers.
> In addition ODF XML has no normalized representation, which make XML references more difficult.
> Therefore the abstraction from XML to logical identities, which are known to users and referencing to those will be easier to handle by general run-time model related to ODF and works well for applications without ODF XML awareness even at run-time.
>
> I have experienced this in my work on a browser based office with Open-XChange in the past years.
> For example, the reference of the 3rd character within the 2nd paragraph might be written as /2/3 which can be seen as a simplification of XPath and was handled by the browser office I have been working with as simple integer array, making things easy for the office at run-time.
>
> Kind regards,
> Svante
>
> On Jan 8, 2016 9:58 PM, "Patrick Durusau" <patrick@durusau.net> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Greetings!
>>
>> I have been following discussions of immutable data structures, mostly
>> in Clojure for several years and it recently occurred to me that if
>> the starting state of an ODF document were immutable and changes are
>> expressed against that immutable state, then many of the problems and
>> issues that have bedeviled the change tracking TC simply disappear.
>>
>> First, since we have an immutable starting state, then changes
>> expressed against that state, for example in XPath (there are ways to
>> default large parts of path statements), represent changes that can be
>> accepted or rejected when producing either a visual, print and/or new
>> version of the document.
>>
>> A "new" version of the document has a new starting state for change
>> tracking and therefore does not reflect the change history of the
>> previous version of the document.
>>
>> A visual or print version of the document would have, expressed as an
>> XPath as well, list of changes that were accepted for that particular
>> visual or print version. Which would mean you could create another
>> visual or print version with different changes reflected. Which would
>> be a separate XPath statement. Enabling you to go back through
>> versions and/or any changes.
>>
>> Second, an immutable starting state and expressions of changes as
>> XPath statements means we can detect when there are conflicting
>> changes, without those changes ever stepping on other changes.
>>
>> For example, assume that we have three paragraphs in the starting
>> state of the document and I delete text:paragraph #2. Since that is
>> recorded as an XPath statement and the original state of the document
>> does not change, you can record changes to text:paragraph #2 without
>> fear of your changes being lost. And you can continue to edit the rest
>> of the paragraphs in the document because to you they have (and do
>> have) the original paragraph numbering.
>>
>> Moreover, if you want to express changes on changes, which are
>> themselves stored in an XML document structure, unlike present
>> applications you can make changes to changes, which while immutable,
>> can have changes specified that point into those changes.
>>
>> Third, and this reaches into the future collaboration sphere of
>> activity, having immutable documents and changes expressed as XPaths,
>> will enable the detection of when branches occur that impact the
>> visual, print or new version, enabling the author to make choices
>> about which branch in the document to accept for that particular version
>> .
>>
>> Moreover, immutable change tracking will enable classic collaboration
>> around a server but also enable collaboration with specified others or
>> within specified groups, such as an authoring group in a highly secure
>> environment.
>>
>> Permissions could also determine what changes could be seen by
>> particular users and where they could suggest changes.
>>
>> I realize this is in stark contrast to the minimal document by default
>> architecture of present change tracking in ODF. That was a good design
>> decision some twenty years ago, facing unreliable networks and a stand
>> alone orientation to document authoring.
>>
>> But twenty years ago isn't where we are in 2016. There are
>> "collaborative" environments already, although I'm not impressed with
>> their capabilities when compared to applications based on ODF.
>>
>> What I am proposing isn't that different from Svante's original
>> proposal except that I propose to solve the problem of coordination
>> between systems by making documents and the changes to be applied to
>> them immutable. Ultimately, serious conflicts must be solved by an
>> author's choice and what I have proposed here will give every author
>> exactly that choice.
>>
>> On the up side, having immutable change tracking the enables
>> applications to have traditional collaboration hubs (think of servers
>> with big targets painted on them), to have collaboration between
>> individual clients at no extra effort, save for receiving the changes,
>> and to have group change tracking for highly secure environments.
>>
>> Oh, I know Svante hasn't pushed this very hard but having immutable
>> change tracking will also enable a variety of platforms to all work on
>> the same ODF document. I may be editing in a desktop application while
>> Svante is editing on a smartphone, which doesn't support styles or svg
>> graphics. All that means is that Svante won't be submitting changes
>> for what his platform doesn't support. He can submit changes for text
>> without any difficulty.
>>
>> Lest that get lost in all my verbage, the "text" is what we say it is
>> when we "accept" changes for the production of a visual, print or new
>> edition. Others may choose differently, as may we at some later point
>> in time. To capture a particular version, create a new edition with no
>> change history. Then it becomes a frozen artifact in time.
>>
>> I suspect this will be of interest to a number of security conscious
>> entities, just for the varieties of collaboration alone. Add in the
>> other capabilities and I think it could be the next jump in
>> collaborative word processing.
>>
>> Hope everyone is at the start of a great weekend!
>>
>> Patrick
>>
>> - --
>> Patrick Durusau
>> patrick@durusau.net
>> Technical Advisory Board, OASIS (TAB)
>> OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
>> Co-Editor 13250-5 (Topic Maps)
>>
>> Another Word For It (blog): http://tm.durusau.net
>> Homepage: http://www.durusau.net
>> Twitter: patrickDurusau
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJWkCMJAAoJEFPGsgi3MgycXaUQANCSZZxva/nL6igv6J8vxzY1
>> Sb3+3WU+fLToiZ7b0qZn+Lq2VkzjZl/kMZ7gKII8TQ6qgSKaUIPdH/2gF2w897Fe
>> fKsluI0n/smqpKwck7M3MrFGBvp+N1eqbgqdpJHOjdOCwKn9Pa5rZ5A3PARxbs8J
>> S9h5/teLQu4TxVIGwwyOpS5W99DrnN6H3CiVM+b1tftplg/d9zih/jslW9wtmHGK
>> ypTCcsNpefLTir9vwgZGBbVoh5VlKBrswrZuLl/Nzv+NlOlCx1pnKqhIcz0L7M0F
>> 4TYpJor90S0oepQLQwzeJ7ZcnLkCvN1CY95RIozLl4h+9PI2twmf+q2N0vE3pgi2
>> 3GoIlMGYlS4eR2SCUQC00gZSD3K1/M58+57/ykfvg3vd85ybTxIREl5R1m/B/euk
>> 8yjLL/doHTYWk6SdZ2PqexDmqf+10jiZ2fBkE0bAIp1MjznAmHxbEyNdXPjYYcHj
>> rh4jB3fR9abE2VXwOtO8ji5p14cVQJX1XUMs9N46FjmKwB0LAEdjdHto/bfPOM2l
>> +qv97x3UNFiGTUy14R4rYrlRXQNUQFgYFT7S6FXIkMPH202vkPjSzRlFNQ0kGKeR
>> YasJslsS2fYuwnO25BgbOms0ewiJJZ8s6VDKsV1r8MHzg0Ah6h5SCWX0za8Xuke4
>> jNKwwl9FS3zuN3Z73NN4
>> =R4zb
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> 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
|