office-collab — archive

[Svante Schubert]

As members of the age of agile development, we should start to prototype, gather further impressions and specify meanwhile. (Might as well the best way to spread the fear, uncertainty and doubt of some members on the list, too.) Our first component(s): For many users, the most important part of documents is the written text. In ODF the written text of a document can not stand alone, it is always within a container. In most cases this container is the paragraph: The root (and only) element of the paragraph component is the text:p as specified in http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-schema.rng In addition every character within the paragraph is counted as component. To gather experience with ODF components and their operations, the test driven approach turned out to be helpful. In particular to map an ODF XML document while loading into the create operations of the known components. This approach allows to test any ODF document at hand being used as operation creator. The approach usually works like this: Most XML based application use the SAX interface to create their document model from XML, esp. the ContentHandler . SAX simply fires events for every start/end of an element, etc. Therefore whenever an ODF element is found in the document being an ODF component, an operation is being triggered to create the component. Components can be nested, therefore the level have to be tracked, so in the end of a component (i.e. </text:p>) the text characters of that levels are being added to the paragraph. To have an easy access on components, the root level components might be added to a list, together with the pointer of the list of their children (creating the component tree by list referencing to lists) and in addition with a pointer to the object in the application representing the component, e.g. XML DOM object of text:p. (A list automatically update all positions, when a component is being inserted). The tree might work like this: Retrieving component /1/11/111 we would look in the first list the first component and retrieve its children list, within this second list getting the 11th component's children list and within that list the 111th child. Operation (serialized as XML) necessary during loading are only the creation of the components, here the paragraph with its text: <add type= paragraph s= /1 >Text of the first paragraph!</add> or we might even take the paragraph as default text container and simply state <add s= /1 >Text of the first paragraph!</add> The position is given by the start parameter (s= /1 ), where 1 is the location of the new desired position of the paragraph in the component tree. For later editing, the deletion of the component is necessary as well. <del s= /1 > Deletes the complete paragraph with all its containing components. <del s= /1/1 e= /1/28 /> Deletes the complete text within the component, but leaves the empty paragraph. Questions and comments? @Patrick: Do you think it makes sense for you to start as well with the specification we want to deliver in the end? I guess Rob and you where thinking of a new ODF spec part, perhaps we could collect some insights on the way? Happy prototyping, Svante