Re: [office-collab] Re: Deletion of Paragraph

["Dr. Peter Rakyta" <rakyta.peter@multiracio.hu>]

Hi Svante!

Unfortunately we missed each other on the SC call.
Regarding the serialization, I would prefer the "generic way", i.e. not to join the operation and the element name into a single tag.

In addition I have a bit silly question. What does notation c: and dc: mean in your examples?

Best regards,
Peter


On 06/15/2016 04:31 PM, Svante Schubert wrote:
> Dear SC,
> 
> Allow me to follow up on these two subjects:
> 
> *Regarding the discussion of XML Serialization:*
> 
> As the ODF changes have been already successfully once implemented as JSON by Open-XChange and provided as open-source solution (Apache License 2)
> at https://code.open-xchange.com/git/office we should start with those a base.
> Certainly the exact serialization might change, like the naming (e.g. "setAtttributes" will become "format") and counting (will start by 1 as usual in
> XML and not by 0), but the concept will remain the same.
> As practical example please take a look at http://markmail.org/message/nv4m77mpfgtqv7dn with the operation list
> of http://markmail.org/download.xqy?id=nv4m77mpfgtqv7dn&number=1
> 
> Our main area of concern should be therefore now the definition of the serialization in XML.
> The final goal is to have two possible transformable serialization in XML (for our ODF package) and JSON for web applications. 
> 
> Let us start with something simple.
> Regarding my question on the serialization of a paragraph deletion (see https://lists.oasis-open.org/archives/office-collab/201606/msg00001.html) I
> did some rookie mistake:
> When there is a deletion of a paragraph from the user, the undo operation to reject the change is of course the inverse function, therefore an
> insertion of a paragraph has to be serialized and not a deletion.
> The undo.xml might look like the following:
> 
> <?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?>
> <undo xmlns="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-collab";
> xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0"  xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0"
> xmlns:dc="http://purl.org/dc/elements/1.1/"; office:version="1.3">
> <changes>
> <info>
> <dc:creator>Unknown Author</dc:creator>
> <dc:date>2016-06-11T15:24:00</dc:date>
> </info>
> <add c:start="/2" dc:type"paragraph" c:style="Standard"/>
> <changes>
> </undo>
> 
> As you noticed, I changed in addition the text:style-name to c:style, avoiding unnecessary complexity of different style attributes.
> 
> That brings me to the design goal for the ODF changes in XML, which should be easy to use, therefore short and mnemonic. I rather would drop existing
> habits we had in previous versions to archive this goal.
> 
> There are of course different ways to serialize the same information:
> 
> One very generic way, which is closer to JSON, but harder to validate with XML.
> (Note: JSON is nothing more as a graph consisting of combination of sequences, maps and values). A direct mapping from JSON to XML would move the type
> from the typed element to an attribute, which might be problematic for XML as the the attribute value is not taken into concern in validation with
> RelaxNG schemas.
> 
> The generic way would look like:
> 
>  1. <add c:start="/2" dc:type"paragraph" c:style="Standard">
>     <prop dc:type"paragraph" outline="1"/>
>     </add>
> 
> The other way is using type oriented element names. I show you just three ways from very verbose to very short, if this is the kind of format to
> follow up I would go for the shortest one.
> 
>  1. <addParagraph c:start="/2" c:style="Standard">
>     <propertiesParagraph outline="1"/>
>     </addParagraph>
> 
> 
>  2. <addP c:start="/2" c:style="Standard">
>     <propertiesP outline="1"/>
>     </addP>
>  3. <addP c:start="/2" c:style="Standard">
>     <propP outline="1"/>
>     </addP>
> 
> The obvious downside is the boost of new elements. It is questionable if a RelaxNG schema is sufficient to validate the sequence of operations. But if
> Schematron with XPath is to be used anyway, the generic solution showed at the beginning will work as well.
> 
> NOTE: For both kind of solutions apply in general: An inner element is created, whenever a new set of values has to be provided like hard formatted
> (automatic) style properties.
> 
> Currently I am undecided but favor to the generic one as it seems more easier to read, more extensible and as it seems that special validation is
> required anyway.
> 
> NOTE: Please remember, although there would be a new namespace with the prefix c as default namespace of the undo.xml file, the attributes still have
> an explicit prefix as the default namespace only applies to elements and not to attributes.
> 
> 
> *Regarding the discussion of bundling a user change:*
> I am still awaiting responses how ODF applications are bundling user changes to a unit to be rejected. 
> 
> 
> Kind regards,
> Svante
> 
> 
> 2016-06-14 11:09 GMT+02:00 Svante Schubert <svante.schubert@gmail.com <mailto:svante.schubert@gmail.com>>:
> 
>     Dear SC,
> 
>     Let's discuss the XML design of a simple change operation: The deletion of a single paragraph.
>     There is a simple test document with three paragraphs, the 2nd should be deleted:
> 
>     <text:p text:style-name="Standard">First paragraph (next paragraph is empty and will be deleted!)</text:p>
>     <text:p text:style-name="Standard"/> <text:p text:style-name="Standard">Third <text:span text:style-name="T2">paragraph</text:span> (earlier
>     paragraph string will be deleted!)</text:p>
> 
>     As a discussion base I would propose the following XML for the undo.xml file:
> 
>     <?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?> <undo
>     xmlns="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-collab"; xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0"
>     xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" xmlns:dc="http://purl.org/dc/elements/1.1/"; office:version="1.3"> <changes> <info>
>     <dc:creator>Unknown Author</dc:creator> <dc:date>2016-06-11T15:24:00</dc:date> </info> <deletion c:start="/2" dc:type"paragraph"
>     text:style-name="Standard"/> <changes> </undo>
> 
> 
>     Some brief comments:
> 
>       * There is a new default namespace for this file with an URL similar to the SC
>       * The changes element embraces a group of changes that should be undone by an ODF application in a single reject. My question to the
>         applications what is their distribution of changes to a single reject?
>       * That there has been a deletion at the position of two is easy to encode, more interesting the serialization of additional component
>         information. Here I encoded the style information as an additional attribute with the same name.
> 
>