OpenDocument - Adv Document Collab SC

  • 1.  Changing the start-tag of an element

    Posted 04-27-2011 02:21
    I take it back. Changing between a heading style and a paragraph style in either direction will definitely change the start tag of an element. It is possible to convert a <text:a> to something else, but that might be a matter of just unwrapping the interior of the <text:a> or turning it into a <text:span>. These is not specifically a consequence of a change of attribute, although it might involve an attribute change at the same time. I don't know if OO.o an LOffice show these as style changes or not, but that is what it looks like to the user, who has no idea about the start tag. - Dennis


  • 2.  Re: [office-collab] Changing the start-tag of an element

    Posted 04-27-2011 08:16
    Hi Dennis, From what I have tried out (using OOo 3.2.1 on Mac OS X), changing a paragraph with a paragraph style into a paragraph with a heading style does not cause any changes to be recorded in OOo. The underlying XML as you say, changes from a text:p to a text:h as well as changing the style name attribute. This element name change will need to be considered, either using the remove-leaving-content / insert-around-content mechanism or with a bucket replacement mechanism. The issue I have with the bucket replacement is that it also causes all of the text content to be deleted and inserted, unless of course a specialized element / attribute can be used to inform the application that this should not be the case. Regards, Tristan On 27 Apr 2011, at 03:20, Dennis E. Hamilton wrote: > I take it back. Changing between a heading style and a paragraph style in either direction will definitely change the start tag of an element. It is possible to convert a <text:a> to something else, but that might be a matter of just unwrapping the interior of the <text:a> or turning it into a <text:span>. These is not specifically a consequence of a change of attribute, although it might involve an attribute change at the same time. > > I don't know if OO.o an LOffice show these as style changes or not, but that is what it looks like to the user, who has no idea about the start tag. > > - Dennis > >


  • 3.  RE: [office-collab] Changing the start-tag of an element

    Posted 04-27-2011 16:33
    I agree that it should not be a bucket replacement. It's not how the user sees it and is clearly unnatural. I would think one would treat it as an exceptional kind of style change (and since style changes are attribute changes) and maybe bundle it with ACT:attribute-change since the progression there needs to be consistent with the changes in the start tag. When working out ACT it might be useful to have an ACT:tag-change rather than attribute-change, and include both start-tag substitutions and attribute modifications of all kinds. It is unfortunate that end-tags do not have attributes, because this would have allowed helpful markers where ODF? alters and inserts/deletes/moves end tags as part insertions and deletions and/or their rejection. Perhaps helpers that track end-tag manipulations could be recorded in the start tags as well, though this may be over-loading and over-constraining the situation. I'm just speculating about that prospect, because the actual invariant conditions for insertion and removal and acceptance/rejection of need to be nailed down first to know what value additional markers or attributes can provide. I note, in passing, that there are different levels of abstraction for some of these. For example, editing the text of a caption should be a text change and not have it matter that it is in the interior of a shape or table object. Also, editing accessibility information may have to be different, depending on whether that is in an attribute value rather than element content, etc., whether it is a link to a content object that is what is actually edited, etc. It may not be suitable to apply a single mechanism to all of these cases, even though we don't want to proliferate mechanisms unnecessarily. - Dennis


  • 4.  RE: [office-collab] Changing the start-tag of an element

    Posted 04-27-2011 17:00
    On Wed, 2011-04-27 at 10:32 -0600, Dennis E. Hamilton wrote: > I agree that it should not be a bucket replacement. It's not how the > user sees it and is clearly unnatural. > If the users sees it, that is: If for example: <draw:frame svg:width="3cm" > <draw:object ... /> <draw:text-box> <text:p> <draw:frame> <draw:image .../> </draw:frame> Caption </text:p> </draw:text-box> </draw:frame> were to contain markup that "Caption" was changed then in some consumers (those that are using the "draw:object") those changes would not be visible. It is not clear to me what accepting all changes in that implementation should do with that change. Note that I would also prefer if the change to the caption would be marked separate from a bucket change but I see lots of difficulties with that (which would apply equally to ECT and GCT except that with respect to the latter we have no idea which restrictions are proposed.) Andreas


  • 5.  RE: [office-collab] Changing the start-tag of an element

    Posted 04-27-2011 17:42
    Andreas reminds us that <draw:frame> is a peculiar element and that the <draw:text-box> might not be rendered by a consumer that only sees the <draw:object> rendering. Now, that Caption is not the caption I was thinking of - it would be more meaningful if the caption paragraph were somehow applicable as part of the <draw:frame> element and applied independent of which of the <draw:frame> child elements was the one that a consumer chose to render. Having change marking in the Caption text below is problematic for both the producer and the consumer. So it is not clear how it got produced, let alone how a consumer deals with it. However, if it is as done in the example from Andreas, an accept all changes would have the change accepted just as a consumer who implicitly accepts all changes would have it accepted. That the user might not know that is happening is a problem in general and it is particularly tricky in the case of <draw:frame>. Showing the entire <draw:text> as having changed wouldn't help that. Showing the <draw:frame> as changed is meaningless, because what is being shown as changed? It can't be the <draw:object> (unless it is changed too). I'd say this problem has to be addressed for <draw:frame> and course-grained doesn't work because of the nature of the element. The same is true for accessibility information as well. We only provide that at the <draw:frame> level, but will that make sense when it is the <draw:text-box> that is rendered, rather than the <draw:object>? - Dennis