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


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

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

Subject: RE: [office-collab] Possible UC7 for consideration...

On Fri, 2011-08-12 at 23:54 +0000, John Haug wrote:
> I’ve had a chance to think about this a little.  To boil it down, I
> see two elements in Ben’s example – the annotation (aka comment) that
> spans across paragraphs and the change made to the annotation’s text.
> Looking at the current specification for office:annotation, its only
> child elements are metadata about the annotation (dc:creator, dc:date,
> meta:date-string) and the annotation text (text:p, text:list).  The
> office:annotation-end allows no children.  The office:change-info that
> stores metadata about a change stores similar info – metadata
> (dc:creator, dc:date) and associated text (text:p).
> For the first element of the example: Is there a benefit to explicitly
> adding change markup to an annotation?  The annotation itself already
> stores the metadata info that change markup adds.  That is, its
> existence can already indicate a change or review “markup” added by a
> user.  It seems redundant to me.
> For the second element: This is of course easily handled by either GCT
> or ECT as a regular text change.

Even when the result is two begin annotation XML elements with the same

> Is change markup for an annotation necessary?

I think this is an interesting point. One thing I should highlight is
that things like annotations, bookmarks, and possibly a collection of
other ODF constructs use begin-end pairs linked with unique names, so
that issue remains open and must be addressed with the ECT.

Although there is overlap, I would personally assume change tracking of
annotations valid. One reason being if I send an ODF file to an editor
and they add 10 annotations with the comments in an ODF tool that
supports change tracking I would like to be able to load and read that
file in a mobile device ODF renderer that doesn't understand change
tracking at all. 

If CT is applied to a GCT ODF file then I should still have the
annotation elements as per normal as well as the CT information for when
I want to act on the editors comments using a more sophisticated tool.

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