OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] The desirability of xml:id stability


On 25/02/13 16:01, Oliver-Rainer Wittmann wrote:
> Hi,
> 
> On 04/02/13 20:55, Michael Stahl wrote:
>> On 04/02/13 18:00, Dennis E. Hamilton wrote:

>>> CASE 3: ODF 1.2 CHANGE TRACKING
>>>
>>> Depending on how references to portions of documents involving tracked
>>> changes happens, there can be a problem with the preservation of xml:id
>>> attributes.  
>>>
>>> In ODF 1.0/1.1/1.2 the connection of change information with the
> places in
>>> the document where the change applies is accomplished by the xml:id
> ID value
>>> on a <text:changed-region> element.  It is also the case that element
> start
>>> tags with xml:id attributes can be swept up into <text:deletion>
> elements
>>> that carry removed material.  Those xml:ids would need to be preserved,
>>> since the deletion can be rejected in a later edit.  (This situation has
>>> remarkable consequences for RDF now referencing an element that is
>>> (partially) deleted.)
>>
>> ah yes... i once spent a day thinking about how to represent xml:ids of
>> merged paragraphs in the change tracking info such that both accepting
>> and rejecting the tracked change yields good results and no additional
>> ODF attributes are necessary due to the uniqueness constraint on xml:id.
>>  i don't remember what my preferred solution was, but Oliver-Rainer
>> didn't like it at the time so maybe it wasn't a good idea  :)
> 
> Unfortunately, I did not even remember the discussion on it.
> 
> Just for my interest: Do you remember the discussed solutions?

not exactly... but i've found an old mail containing some Wiki dump
which i'll forward you privately... apparently the "solution" was to
lazily join the xml:id of the paragraphs not when a tracked change is
created but when it is accepted, which you and/or AMA didn't like
because it violates the usual principle that the content of the document
(ignoring tracked changes) represents the state in which all tracked
changes are accepted.

regards,
 michael

-- 
Michael Stahl | Software Engineer
Platform Engineering - Desktop Team
Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]