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

Hello Peter,

I have updated the example to delete just a heading, which follow a paragraph and attached an updated undo.xml.

The relevant XML of the content.xml looks like:

<text:p text:style-name="Standard">First paragraph (next will be deleted!)</text:p>

<text:h text:style-name="Heading_20_3" text:outline-level="3"/

More info below...

2016-06-15 16:53 GMT+02:00 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.

I have as well the tendency to the generic way. What are your reasons?

To me it seems easier to read and has less XML nodes to define. Validation needs to be done by XPath & Schematron anyway and user might have the chance to transport additional information like user-defined information without another extension of the parser/reader.

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

I first explained you what namespaces are, than I realized that you might wanted to point out to validation errors in the XML. I should validate my examples before I write them in public. I missed an equitation dc:type="paragraph" and the definition of c as I made it later to the default namespace.

But as I have explained it already in length, allow me to sent the text anway.

The attribute prefixes c and dc are the prefixes for the XML namespace. Their purpose is to make the XML element unique. The prefix itself is just a volatile information and will be exchanged during parsing time with the URI that is declared prior in the XML document.

For instance, "dc" is the abbreviation for Dublin Core and will be mapped via xmlns:dc="http://purl.org/dc/elements/1.1/" to an URL. So I have reused dc:type

which then points to the follwing URL

http://purl.org/dc/elements/1.1/type

browsed with a user-agent it is resolved to the HTML page behind

http://dublincore.org/documents/dcmi-type-vocabulary/#elements-type

Even dublincore.org is defining another type, which has a different URL prefix

http://purl.org/dc/terms/type

browsed with a user-agent it is resolved to the HTML page behind

http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#type

The difference between those types is the first is a term and the latter is being used to describe the type of this term. No idea, why they did not used the same term on itself.

Long story short, our <text:p> element is equivalent to a <Peter_Rakyta:p> element as long both prefixes "text" and "Peter_Rakyta" are being resolved to the same URL "urn:oasis:names:tc:opendocument:xmlns:text:1.0". In the Apache ODFDOM library I am normalizing different prefix of the URLs being used in the standard to the usual ones.

Last thing, oppose to the multiple declaration of namespaces such as xmlns:dc="http://purl.org/dc/elements/1.1/" there can be one default namespace that can be ommitted, I have choosen xmlns="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-collab".

In the end I will attach the undo.xml file, when deleting a heading level 3 at position 2.

Regards,

Svante

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.
>
>

---------------------------------------------------------------------
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

office-collab message