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...

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.


Is change markup for an annotation necessary?


From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com]
Sent: Monday, August 01, 2011 7:56 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Possible UC7 for consideration...



This looks like a good example. It would be good to have the various versions of the document in full so we can be sure about what is intended - that is how we have been doing use cases (and you have done UC8 this way). Then your GCT solution can be checked more easily, and an ECT can be crafted.

Please add to documents here:
http://www.oasis-open.org/apps/org/workgroup/office-collab/documents.php under Use Cases
and to the wiki here:
probably under multiple changes or other.

If you are in the call tomorrow we can check with others that this use case is another useful one to do in detail, otherwise we will add it to the main set as above. We need to be sure that the issues in this use case are not covered in the other use cases UC1 to UC6 which we are looking at in detail.


On 25/07/2011 06:08, monkeyiq wrote:

  While indexing up the UC1-UC6 I was also trying to think of other cases which might present sticky results. Looking at the ODF 1.2 spec, in particular the section for annotations I see the provision for annotations to span across elements:

14.2 <office:annotation-end>
  The <office:annotation-end> element may be used to define the end of a text range of document content that spans element boundaries. In that case, an <office:annotation> element shall precede the <office:annotation-end> element. Both elements shall have the same value for their office:name attribute.

I thus propose a UC7 which includes an annotation spanning from one text:p to another as follows. Note that the same issues arise for text:bookmark-end ( Though I arrived at this because one might very well want an annotation to link a disparate range.

In the example, First the paragraph text for all three paragraphs is inserted. Then the draw:frame and its caption text is added. Then an annotation is inserted spanning through the end of the caption through another paragraph and midway into the next one. Finally a word is inserted into the caption, inside the bounding region that is included in the annotation region.

In this case, for the GCT there is only the original office:annotation using its original office:name attribute. The use of buckets in the ECT would appear to make things quite sticky. One solution might be to include the whole office:annotation in each bucket and each time link back to a different annotation/office:name from the annotation-end marker. Another might be to extend the definition of office:name to allow one or more previous annotations to have the same identifier which is picked up by a single annotation-end element.

A crack at GCT for this case follows.

<text:p text:style-name="Text_20_body">
  <draw:frame draw:style-name="fr1" draw:name="Frame1" 
              text:anchor-type="paragraph" draw:z-index="0" 
              svg:x="2.0cm" svg:y="2.0cm" svg:width="8.0cm" 
    <draw:text-box fo:min-height="2.503cm">
       <text:p text:style-name="Frame_20_contents">
          This is 
          <office:annotation office:name="supereffective"
            <text:p text:style-name="Normal" >
                This part of the document rocks amigo!
          text frame.
In this example an annotation has been created which spans from the  
text:p of the comment for an image through this paragraph and into the next.
  Perhaps we have missed considering locality in the document. 
  And this part is more about the water cooler and how we all need to
  get more sun this winter. 

-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

--------------------------------------------------------------------- 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

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