Re: Fwd: A sort of synthesis

One option which I don't think has been discussed, but holds a lot of merit
is a combination of using a differencing engine, and annotations in the
document. If a standardized method of annotating changes could be adopted
(even if it was externalized), then it could be used in conjunction with a
good differencing engine. The engine could read in changes from multiple
copies (along with the annotations), intelligently merge them, and recreate
the annotations in the result document.

In terms of interoperability, this presents the easiest approach for
existing editors to adopt, because they could convert to and from this
format easily, and edits from third party systems could easily be
incorporated as well. Even if those changes were not made in a "editing
tool" (for instance changes made by a script that modifies files in some
way).

IMHO, This is the only approach which satisfies requirements with respect
to interoperability and durability of change tracking.


On Mon, Mar 11, 2013 at 3:53 PM, Casey Jordan <casey.jordan@jorsek.com>wrote:

>
> Dennis you are correct in your assumptions about XPath, and while I think
> Claudius is on the right track by using something like XPath, it would
> probably make more sense to use a very constrained version of a "range" (IE
> Two points in a document).
>
> Take for instance this document:
>
> <topic>
> <title><b>Hello</b> everyone!</title>
>
> </topic>
>
> Given any tree structure we could represent a range in the with a pair of
> locations (start, end) and offsets. The node would be indicated by a
> position vector, and the offset by the caret placement in that node.
>
> Consider indicating that someone selected and deleted "Hello everyone!".
> The range would be:
>
> (Start: [0.0.0.0, 0], End [0.0.1, 10])
>
>
> The x.x.x sequence indicates the nodes position in the document. IE: The
> document element is at position 0. The title element is at position 0 with
> respect to it's parent, and so on.
>
> So [0.0.0.0, 0] indicates that the start node is the "Hello" text node,
> and the start position is at the beginning of the nodes character data (0).
>
> [0.0.1, 10] indicates that the end node is the " everyone!" text node, and
> the end position is at the end of the nodes character data (10)
>
> This method is simple, throughout and could be easily standardized.
>
> The only issue with externalizing information like this is you always need
> to be able to understand how changes effects the addressing of these
> elements. Since there is no unique id for each element, moving an element
> would mean these addresses would need to be modified to represent the new
> correct location. In a single user editing scenario (Only one user editing
> at a time) this is simple.
>
> In an collaborative environment this becomes very complex. Which is one of
> the reasons PI's in the document are often chosen over this method.
>
>
> Cheers,
>
> Casey
>
>
> On Mon, Mar 11, 2013 at 2:42 PM, Dennis E. Hamilton <
> dennis.hamilton@acm.org> wrote:
>
>> I suspect that XPath works for pure XML change-tracking, although I have
>> a question.
>>
>> I am not conversant enough with XPath to see whether it can isolate a
>> point *within* a text node.  My superficial examination of XPath 1.0/2.0
>> suggests that there is no path expression into the interior of a text node.
>>  Is that considered a problem here, or is there a well-known way of
>> addressing that?
>>
>>  - Dennis
>>
>> PS:
>> One reason for external tracking, if I wasn't clear about it, is to
>> preserve any DSig on the original.  The combination might then be signed by
>> the source of the changes and this can be recursive.  The downside is that
>> one can't have the default interpretation of the document, ignoring the
>> external changes, be the form that is seen with all changes accepted.
>>  (Think about a contract offer and its
>> back-and-forth markup.  Another case would be turnaround documents that
>> are rendered as forms, but the form itself is immutable [signed] and the
>> field entries are handled in a manner akin to changes.  There's a special
>> case of this last case in how Microsoft Office projects visible signature
>> images onto signature-block fields of digitally-signed OOXML documents.)
>>
>> The use case of concern for me, along with the above consideration, is
>> for documents whose models are such that a perceived change effectively
>> severs (cross-cuts) elements in the underlying XML, splicing parts from
>> different elements into single ones across the scar where the severed
>> pieces come together.  (There is a comparable insertion case.)  I don't
>> expect that to be an use case for this project; I'm watching for anything
>> that might be adaptable for that, though.  XPath might still serve in such
>> elaborate cases.
>>
>>  - Dennis
>>
>> -----Original Message-----
>> From: Claudius Teodorescu [mailto:claudius.teodorescu@gmail.com]
>> Sent: Monday, March 11, 2013 09:20
>> To: Randall Leeds
>> Cc: liam@w3.org; dennis.hamilton@acm.org; public-change@w3.org
>> Subject: Re: Fwd: A sort of synthesis
>>
>> A good representation of changes can be in or out of the respective
>> document.
>>
>>
>> For out case, doesn't seem to pose so many difficulties.
>>
>>
>> As to the inside XML document case ... what if we can design something we
>> can call "change tracking instructions", in order to graciously store
>> metadata about changes inside the document?
>>
>>
>> Claudius
>>
>>
>> P. S. For Dennis E. Hamilton: I would specify the tracked changes by
>> using XPath.
>>
>>
>>
>> [ ... ]
>>
>>
>>
>>
>
>
> --
> --
> Casey Jordan
> easyDITA a product of Jorsek LLC
> "CaseyDJordan" on LinkedIn, Twitter & Facebook
> (585) 348 7399
> easydita.com
>
>
> This message is intended only for the use of the Addressee(s) and may
> contain information that is privileged, confidential, and/or exempt from
> disclosure under applicable law.  If you are not the intended recipient,
> please be advised that any disclosure  copying, distribution, or use of
> the information contained herein is prohibited.  If you have received
> this communication in error, please destroy all copies of the message,
> whether in electronic or hard copy format, as well as attachments, and
> immediately contact the sender by replying to this e-mail or by phone.
> Thank you.
>



-- 
--
Casey Jordan
easyDITA a product of Jorsek LLC
"CaseyDJordan" on LinkedIn, Twitter & Facebook
(585) 348 7399
easydita.com


This message is intended only for the use of the Addressee(s) and may
contain information that is privileged, confidential, and/or exempt from
disclosure under applicable law.  If you are not the intended recipient,
please be advised that any disclosure  copying, distribution, or use of
the information contained herein is prohibited.  If you have received
this communication in error, please destroy all copies of the message,
whether in electronic or hard copy format, as well as attachments, and
immediately contact the sender by replying to this e-mail or by phone.
Thank you.