<office:body>
<office:text>
<delta:remove-leaving-content-start ...>
<foo/>
</delta:remove-leaving-content-start ...>
<...> [all this original content of <foo> must be allowed not only in foo but also in office:text, as Frank notes]
....
</...>
<delta:remove-leaving-content-end .../>
</office:text>
</office:body>
Note also section 7.2.1 to 7.2.3 of the generic-ct-proposal contains details of some constraints that will always be applicable, so the generic proposal is not a 'free for all'. Of course, as has been suggested, there could be more constraints for ODF.
We did make some modifications to the relaxng schema to cover the use case samples, and this would need to be extended to the rest of the schema. There is a choice about how this is done of course, and specific delta elements could be disallowed in specific places as deemed necessary to constrain it.
Another constraint method would be to identify the edit operation types as meta data in the change-transaction, e.g. 'global word replacement', and then constrain this to contain only text additions and deletions (that would need schematron I think, it could not be done by relaxng).
Regards,
Robin
On 06/04/2011 10:38, Frank Meies wrote:
4D9C34A0.9080701@oracle.com" type="cite"> Hi Thorsten,
On 06.04.2011 11:03, Thorsten Behrens wrote:20110406090330.GD31629@thinkpad.thebehrens.net" type="cite">
No, the thing I had in mind was more like <office:body> <office:text> <delta:remove-leaving-content-start ...> <...> <...> <...> .... </...> </...> <...> .... </...> . . . </delta:remove-leaving-content-start ...> <...> .... </...> <delta:remove-leaving-content-end .../> </office:text> </office:body>
but as far as I understood delta:remove-leaving-content, it is intended to remove *only one* element without touching the content (this of course needs to be specified precisely, see below), and if you actually remove the element, the resulting ODF must be valid. So the only possible use cases that I can imagine for this is removing a span and removing a plain section but leaving the content as is (and I'd drop the second one because it is not very common).
20110406090330.GD31629@thinkpad.thebehrens.net" type="cite">For making ct transactions individually acceptable and rejectable, of course also the inverse, modulo nested added / removed content inside the delta:remove-leaving-content-start block, action needs to be possible inside the application core - i.e. you *will* need to transform that xml into actionable editing instructions on the internal document model, i.e. be able to glean the semantics of that markup on your doc ...
Yes, sure.
20110406090330.GD31629@thinkpad.thebehrens.net" type="cite">So I maintain that, for being implementable with reasonable effort, via a non-xml-based representation, the generic ct is heavily under-constrained. :)
Well, yes, that's what I also asked for in one of my first mails (see http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201101/msg00002.html).
Regards,
Frank
--
Frank Meies | Software Developer
Phone: +49 49 23646 500
Oracle OFFICE GBU
ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
Oracle is committed to developing practices and products that help protect the environment
-- -- ----------------------------------------------------------------- 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