[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-collab] Possible UC7 for consideration...
|
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. -----Original Message----- 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 -----Original Message----- From: Robin LaFontaine
[mailto:robin.lafontaine@deltaxml.com]
Sent: Monday, August 15, 2011 03:17 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Possible UC7 for consideration... On 13/08/2011 00:54, John Haug wrote: ..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
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
--------------------------------------------------------------------- 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
-----Original Message----- From: monkeyiq [mailto:monkeyiq@gmail.com] Sent: Saturday, August 13, 2011 3:08 PM To: John Haug Cc: office-collab@lists.oasis-open.org 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 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]