[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-collab] Re: Deletion of Paragraph
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]