office-collab — archive

[Svante Schubert]

Hi Patrick, A meta issue deserves a meta answer. We would count as our scenarios demand us to do I personally would count as simple as possible. Allow me to point out the following example that had been on the list before. (The changed text was made underlined/cursive for showing purpose, no styling intended) Ending markup: < text:h > Some important text! </ text:h > Starting markup: < text:h > Some text. This could be a very long text! </ text:h > < text:p > New text! </ text:p > < text:p > Existing i mportant text! </ text:p > The ordered set of undo operations to undo the changes and go from the ending markup to the starting markup could be: <undo>     <split s= /1/6 />     <add s= /1/6 >text. This could be a very long text!</add>     <add s= /2 >New Text!</new> <add s= / 3 /1 >Existing </add> </undo> The above operations are being executed by the application one after another in timely sequence, as writing from the top to the bottom. Every operation is relative to the state of the document just before the operation is being executed. Therefore reordering the operations is like moving them in time! As result to this the numbers of the arguments might be increased (or decreased) when the operation is being moved up/down, as components earlier counted have or have not existed before. For example, moving the last operation one up, is like the operation     <add s= /2 >New Text!</new> has not yet being executed, and would result in a stack as <undo>     <split s= /1/6 />     <add s= /1/6 >text. This could be a very long text!</add> <add s= / 2 /1 >Existing </add>     <add s= /2 >New Text!</new> </undo> The component count of root level children is decreased by one, as the <text:p>New Text!</text:p> has not been created yet. To ease counting and adapting of parameter, I suggest not to count type dependent (e.g. text:p[24]) and in addition as most components are being used cross document wide (e.g. html, docbook, ooxml), I would personally would prefer to use the more verbose human readable form, i.e. paragraph instead of text:p. But in the end the component name is only a working title. In the as XML serialized form of operations, the component name could again be abbreviated, e.g. back to the local name of the ODF XML root element, when being used. Best regards, Svante On 12.09.2012 15:54, Patrick Durusau wrote: Greetings! Sorry to be bringing up another meta issue so soon but it occurs to me that we need to decide not only *what* we are going to count (Svante's components) but *how* we intend to count them. In such a way that allows for implementations to have whatever internal representations, from tables and DOM trees to more sophisticated structures. That is to say I view the component identification <-> implementation model as follows: ODF defines interchangeable component identification -> mappingTo (defined by implementations) -> Implementation Model Implementers define Implementation Model(s) and, mappingTo -> ODF defined interchangeable component identification Having said that, and speaking only of elements, I would suggest that we follow the already defined elements with their namespaces, followed by the count of that element in the document as the designation for an element. thus (ignoring path): text:p[24] would be the 24th text:p element in a document. I thought about simply counting everything and relying solely on address/count but that would limit the internal models you could use. with text:p[24] you can use whatever internal structure you like, so long as it can find and report text:p[24]. *** Having said that, I think counts should start with 1 and accept up to 32-bit integers (I don't want to have to revisit this anytime soon.) Oh, and counts need to start at the root of each XML file, such that we can lose all the files in a package except CT and content.xml (or even part of it) and still be able to apply all of the change tracking that retains targets in content.xml file. *** Does the count starting at the root of each XML file imply we need some internal CT file structure other than operations and paths? That is do we track changes to styles themselves separately from application of styles? My gut says no but am interested in other opinions. Mostly saying no because if we make change tracking overly clever, the more fragile it will become. Thinking the better course is like a key/value pair: operation - path with change True, an implementation has to know that style:style isn't found in content.xml but that isn't a high expectation. Sorry, did not mean to cover so many issues in one post, summary: (1) Counting starts with 1 for each component and continues up to 32 bits (anything in excess of 32 bits is an error, discard, don't allow buffer overflow) (2) Components (elements) are designated by namespace:elementName[count] (3) Counting starts at the root of each file (4) CT entries are recorded in the order of application in the CT file as operation - path with change (operations, paths, change subject to definition by the SC) This one may take a while on a call, even with vigorous email discussion. Hope everyone is having a great day! Patrick PS: Almost forgot: What do we call the CT file? Taking the SGML route: TBCBPDAGDHJHMJRLDMFMTMARSSRWORW.xml seems a bit verbose. Suggestions for something shorter? Or do you want to use that as a working name? ;-)