Fwd: Change tracking processing instructions and deletion

---------- Forwarded message ----------
From: Claudius Teodorescu <claudius.teodorescu@gmail.com>
Date: Wed, Sep 17, 2014 at 2:42 PM
Subject: Re: Change tracking processing instructions and deletion
To: Robin LaFontaine <robin.lafontaine@deltaxml.com>


Hi,

On Thu, Sep 4, 2014 at 5:44 PM, Robin LaFontaine <
robin.lafontaine@deltaxml.com> wrote:

>  Hi Claudius,
>
> I think one issue with XQuery Update for change tracking is that although
> it looks good for one transaction, it does not work well for multiple
> transactions because the XPaths will change as the document is changed.
> In theory you could undo the changes in order (though only if every
> change had been tracked), but it would be almost impossible to undo in any other
> order with predictable results.
>

You can have one transaction containing multiple update operations, like:
<?change user="nigel" time="2014-08-27 15:12:00" change="(delete node
//p[1], insert node &lt;p xml:lang="en"&gt;Hello World&lt;/p&gt; into
//body)" ?>.

But, this will not work with randomly acceptance/rejection of changes, as
you said. On the other hand, dealing with random acceptances/rejections is
hard for separate change logs, not matter how they are written.

Keeping the change log within the document is needed to be a positional
approach, in order to allow random acceptances/rejections, as the change
log records are to be nearby the former/new content.

So, this positional approach seems to be the answer for change log kept
within document.

I wonder if this system has some issues with nested changes, either for
undoing or for accepting/rejecting any of them.


Claudius



> Consider also a document with a series of XQuery Update changes, it would
> be quite hard to work out how to display these changes, but much easier if
> the changes are embedded in PIs within the document (or indeed in markup).
>
> There is a design decision about where to keep the changes:
> 1. Within the document
> 2. Separate, e.g. in a series of transactions in XQuery Update
>
> Most current systems I believe use choice 1, either as markup (e.g. Word,
> ODF, Arbortext) or PIs (e.g. oXygen, XMetaL, Xopus). I think there are good reasons
> for this choice.
>
> Robin
>
> * --*
> *Robin La Fontaine*
> Director
>  *DeltaXML Ltd* *"Experts in information change"*
>
>  *T*: +44 1684 592 144
> *E*: robin.lafontaine@deltaxml.com
> *W*: http://www.deltaxml.com
> Malvern Hills Science Park, Malvern, Worcs, WR14 3SZ, UK
> Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
>
>   On 28/08/2014 17:49, Claudius Teodorescu wrote:
>
>    Hi,
>
>
>  It is very nice to see PIs used to track changes. Last year, when I
> mention PIs as a method for track changes, on this list, I had no clue they
> were used.
>
>  As to syntax for effectively track changes, why not use XQuery Update?
>
>  Your example would become:
>
> <?change user="nigel" time="2014-08-27 15:12:00" change="delete node
> //p[1]" ?>
>
>  for example.
>
>  Another example
>
> <?change user="nigel" time="2014-08-27 15:12:00" change="insert node <p
> xml:lang="en">Hello World</p> into //body" ?>.
>
>  Thus, it is plain what p element was deleted (as the respective XPath
> expression identifies it clearly for the respective version of document)
>
>  The only overhead is that the deleted content has to be stored, too, in
> order to revert the changes, etc.
>
>
>  Claudius
>
>
> On Wed, Aug 27, 2014 at 5:59 PM, Nigel Whitaker <
> nigel.whitaker@deltaxml.com> wrote:
>
>>    Hello everyone,
>>
>>  There's an aspect of the existing change tracking PIs that are used in
>> a number of systems that I've often wondered about:
>>
>>  The PIs that are used follow the convention of using an attribute-like
>> syntax.  Its a convention that's been adopted for standard PIs such as
>> xml-stylesheet and xml-model.
>> While its a convention, the XML spec itself doesn't say a lot about what
>> you can/can't do in a PI
>>
>>  When content including elements and attributes is deleted in change
>> tracking systems the content is typically escaped so that its a legal
>> attribute.
>>
>>  Suppose I was to delete this paragraph:  <p xml:lang="en">Hello
>> World</p>
>>
>>  We may see something like this (I'm generalising from what I've seen in
>> a number of systems):
>>
>>  <?change user="nigel" time="2014-08-27 15:12:00" delete="&lt;p
>> xml:lang=&quot;en&quot;&gt;Hello World&lt;/p&gt;" ?>
>>
>>
>>  The angle brackets and quotes have been 'escaped' to make it a legal
>> attribute.  I've got code to deal with this process, but I do wonder if its
>> necessary and if things could be simplified?
>>
>>  If we don't use attributes we could perhaps do this:
>>
>>  <?change
>>   <delete>
>>     <dc:creator>nigel</dc:creator>
>>     <dc:time>2014-08-27 15:12:00</dc:time>
>>     <deletedContent><p xml:lang="en">Hello World</p></deletedContent>
>>   </delete>
>> ?>
>>
>>  The pseudo-attribute based representation is more compact for small
>> cases certainly, but if there's a large amount of deleted content then the
>> size needed for escaping grows.
>>
>>  And with the XPath3/XLST3 parse/serialize functions coming soon (and
>> saxon:parse()) would an 'element based PI'  be easier for new-comers to
>> read and process?  And perhaps there could be a convention of using a .xsd
>> or .rng grammar to specify the PI content.
>>
>>
>>  It's not a big issue for me - I've written the code for handling the
>> escaping, but I've often wondered if things could be easier.
>>
>>  I wonder if there are any advantages to the attribute like notation,
>> other than its a convention that's always been followed.  Does anyone know
>> the history here?
>>
>>  Thanks,
>>
>>  Nigel
>>
>>
>>   --
>> Nigel Whitaker - DeltaXML Ltd - nigel.whitaker@deltaxml.com
>>
>>
>
>
> --
> http://kuberam.ro
> http://kuberam.ro/art
>
>
>


-- 
http://kuberam.ro
http://kuberam.ro/art



-- 
http://kuberam.ro
http://kuberam.ro/art