OpenDocument - Adv Document Collab SC

  • 1.  Possible UC7 for consideration...

    Posted 07-25-2011 05:09
    Hi,   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 (6.2.1.4). 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"               delta:insertion-change-idref="ct2"               delta:insertion-type="insert-around-content">             <dc:creator>Superman</dc:creator>             <dc:date>7-25-2011</dc:date>             <text:p text:style-name="Normal" >                 This part of the document rocks amigo!             </text:p>             </office:annotation>             a           <delta:inserted-text-start               delta:insertion-change-idref="ct3"               delta:inserted-text-end-idref="it1"/>             modified           <delta:inserted-text-end               delta:inserted-text-end-id="it1"/>           text frame.        </text:p>     </draw:text-box>   </draw: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. </text:p> <text:p>   Perhaps we have missed considering locality in the document.   <office:annotation-end      office:name="supereffective"      delta:insertion-change-idref="ct2"      delta:insertion-type="insert-around-content"/>     And this part is more about the water cooler and how we all need to   get more sun this winter. </text:p>


  • 2.  Re: [office-collab] Possible UC7 for consideration...

    Posted 08-01-2011 14:56
    Ben, 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: http://wiki.oasis-open.org/office/ChangeTrackingUseCases 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. Thanks, Robin On 25/07/2011 06:08, monkeyiq wrote: Hi,   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 (6.2.1.4). 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                           delta:insertion-change-idref= ct2                           delta:insertion-type= insert-around-content >                       <dc:creator>Superman</dc:creator>                       <dc:date>7-25-2011</dc:date>                       <text:p text:style-name= Normal >                               This part of the document rocks amigo!                       </text:p>                       </office:annotation>                       a                   <delta:inserted-text-start                           delta:insertion-change-idref= ct3                           delta:inserted-text-end-idref= it1 />                       modified                   <delta:inserted-text-end                           delta:inserted-text-end-id= it1 />                   text frame.             </text:p>       </draw:text-box>   </draw: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. </text:p> <text:p>   Perhaps we have missed considering locality in the document.   <office:annotation-end         office:name= supereffective         delta:insertion-change-idref= ct2         delta:insertion-type= insert-around-content />     And this part is more about the water cooler and how we all need to   get more sun this winter. </text:p> -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK


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

    Posted 08-12-2011 23:55




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


     
    Ben,

    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:
    http://wiki.oasis-open.org/office/ChangeTrackingUseCases
    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.

    Thanks,
    Robin


    On 25/07/2011 06:08, monkeyiq wrote:
    Hi,
      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 (6.2.1.4). 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"
                  delta:insertion-change-idref="ct2"
                  delta:insertion-type="insert-around-content">
                <dc:creator>Superman</dc:creator>
                <dc:date>7-25-2011</dc:date>
                <text:p text:style-name="Normal" >
                    This part of the document rocks amigo!
                </text:p>
                </office:annotation>
                a
              <delta:inserted-text-start
                  delta:insertion-change-idref="ct3"
                  delta:inserted-text-end-idref="it1"/>
                modified
              <delta:inserted-text-end
                  delta:inserted-text-end-id="it1"/>
              text frame.
           </text:p>
        </draw:text-box>
      </draw: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.
    </text:p>
     
    <text:p>
      Perhaps we have missed considering locality in the document.
      <office:annotation-end
         office:name="supereffective"
         delta:insertion-change-idref="ct2"
         delta:insertion-type="insert-around-content"/>
     
      And this part is more about the water cooler and how we all need to
      get more sun this winter.
    </text:p>
     



    --
    -- -----------------------------------------------------------------
    Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
    T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
    http://www.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






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

    Posted 08-13-2011 22:08
    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 name? > > > > 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.


  • 5.  Re: [office-collab] Possible UC7 for consideration...

    Posted 08-15-2011 10:17
    On 13/08/2011 00:54, John Haug wrote: 91C4760493E4094B9871E5A496374DA23B193AA6@DF-M14-03.exchange.corp.microsoft.com type= cite > ..snip   Is change markup for an annotation necessary?   We do have this requirement: 2.4 Track all possible types of change - track all types of change, e.g. across hierarchy, tables, styles etc. It is clear that ECT cannot track changes in annotation at the moment, but how easy or difficult it is to extend it to do this will help to inform our decision. We need to know if we need significant work and several pages of examples/documentation for every new construct we wish to include. Alternatively, if ECT cannot be extended to do this, then we need to know that if we go with ECT then we cannot track changes in annotation or any similar constructs. Robin -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK


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

    Posted 08-15-2011 17:34
    I think there may be a misunderstanding about what "ECT" (and ODF 1.2 already) can do with annotations. The <office:annotation> element has change-trackable content. This is provided in the content of the annotation itself, which consists of paragraphs and lists. I don't believe the <office:annotation-end> is used to mark the end of the annotation but the end of the normal text that the annotation applies to. (That is, it is the difference between the annotation applying at point and applying to a segment of the visible content of the document.) In that sense, it is like a bookmark, end, when present and in that case the <office:annotation> is like a bookmark start while also providing the content of the annotation in its own child elements. Also, the office:name is not an ID, so "duplicates" are not an issue the way they are for ID-valued markers. Finally <office:annotation-end> is new in ODF 1.2 and the explanation of it is all there is to be seen. The absence of semantics is really wonderful, isn't it? The same goes for the attributes on <office:annotation> that appear to treat the annotation contents as fitting within a type of frame insertion. It is not expected that any change in the annotation itself could have a span that is partially in and partially without the annotation, any more than one would expect that with any other kind of framed content. It is outside of the running text. When an <office:annotation-end> appears, there is also the consideration if the <office:annotation> were, in addition to providing the annotation, treated like a bookmark start having the <office:annotation-end> as the end marker. In that case, the previously unsolved problem with regard to change-marking of off-hierarchy begin and end markers applies, but that is not to change in the annotation but in what the annotation applies to, it seems to me. It would be interesting to find an implementation of <office:annotation-end> to see how it is used, if at all. - Dennis


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

    Posted 08-15-2011 18:12




    Ben: Even when the result is two begin annotation XML elements with the same name?
    My thinking here was that it is up to the application to ensure it doesn ??t duplicate names if that ??s not allowed.  Same as the myriad other places that rule applies.  Dennis points out it ??s not an ID and doesn ??t have the same kind of
    document validation baggage an ID would, though 19.376.6 does require the name must be unique for each pair of annotation / annotation-end.  The ID question you raise sounds like the question your UC8 raises.  That also seems to me to be a largely straightforward
    case of the app needing to be aware of names/IDs in use and not introduce duplicates.
     
    Ben: One reason being if I send an ODF file ?¦
    I don ??t think that scenario is invalidated.  The annotation itself carries around the info that change markup does, so it still seems duplicate.  A simple reader application can still ??see ? annotations and show when they were added and
    by whom.
     
    Robin: track all types of change ?¦
    Regardless of how broad this rather bold statement is, I still don ??t think we ??re losing anything by not including change markup that duplicates the information that annotations already contain.
     
     



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

    Posted 08-15-2011 20:59
    On Mon, 2011-08-15 at 18:12 +0000, John Haug wrote: > Ben: Even when the result is two begin annotation XML elements with > the same name? > > My thinking here was that it is up to the application to ensure it > doesn €™t duplicate names if that €™s not allowed. Same as the myriad > other places that rule applies. Dennis points out it €™s not an ID and > doesn €™t have the same kind of document validation baggage an ID would, > though 19.376.6 does require the name must be unique for each pair of > annotation / annotation-end. The ID question you raise sounds like > the question your UC8 raises. That also seems to me to be a largely > straightforward case of the app needing to be aware of names/IDs in > use and not introduce duplicates. One subtle difference between rewriting an xml:id and changing the begin/end name occurs to me. For the xml:id case, when making a bucket you can add new RDF to make sure the things linked to the old (existing) xml:id are linked to the new xml:id used in the bucket. If you update the name used for the begin XML element for a bookmark or annotation then there is no longer a matching end XML element for it. So you either get two begin markers with the same name or a begin marker without an end marker.


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

    Posted 08-16-2011 00:26
    Isn't that just a case of the application realizing it's changing one name of a pair and not leaving the other an orphan?




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

    Posted 08-17-2011 07:38
    On Tue, 2011-08-16 at 00:26 +0000, John Haug wrote: > Isn't that just a case of the application realizing it's changing one > name of a pair and not leaving the other an orphan? I think two markers become three during the changes if you throw a bucket in there leaving one a dangling reference. > >