[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-collab] How do we count? - September 26, 2012
Perhaps I haven't absorbed all this sufficiently yet, but I've had a reservation about MCT I've never understood enough to fully prove. Doesn't all this relative positional referencing cause difficulty for an implementation? As Svante noted early in the thread: >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. So each time an arbitrary change is rejected or the document content is altered (change-tracked or not), the numerical references of some/all the change tracking markup may be invalidated and must be recalculated by the application, right? That seems like a significant and unavoidable burden. I was a hardware guy in school, not a software/algorithms guy, but that has to be unpleasant big-O behavior! Or am I (hopefully!) wrong in my understanding? John -----Original Message----- From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Patrick Durusau Sent: Friday, September 21, 2012 12:40 PM To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] How do we count? - September 26, 2012 Oliver, On 09/21/2012 09:26 AM, Oliver-Rainer Wittmann wrote: > Hi, > > sorry for stepping in soo late and also sorry for top-posting. > > I am at the beginning of getting deep into the current change tracking > stuff. Thus, please correct and help me, if I am wrong, because of > lack of deep insight. > > From my point of view a type-dependent counting does not makes sense. > Reason - look at the following sample: > > - Ending markup: > <text:p> > <text:table> > <text:section> > <text:p> > > - Starting markup > <text:p> > <text:table> > <text:p> > <text:section> > <text:p> > > - Undo > <add type="paragraph" /2 ...> > > Having the Ending markup and the Undo I do not know where the <text:p> > element needs to be inserted (before <text:table>, after <text:table> > and before <text:section> or after <text:section> to undo the tracked change. But you do have the necessary information. When you say "starting markup" what is really meant is that if the internal representation were serialized into ODF conformant XML, it would appear thus: <text:p> <text:table> <text:p> <text:section> <text:p> But the information that composing the document isn't held that way by the application (or isn't necessarily held that way). The XML serialized format conceals the fact that all those elements have an absolute numbering relative to each other. Thus: [1]<text:p> [2]<text:table> [3]<text:p> [4]<text:section> [5]<text:p> And the application "knows" that the element [5]<text:p> follows element [4]<text:section> In the XML, that ordering information isn't explicit but is left implied. So if I say: Undo <add type="paragraph" /2 ...> The insertion of the paragraph /2 occurs in the editor, after [2]<text:table>, just as it does now. (In other words, the editor tracks the location of changes just like it does now. However it does that internally. All that is required is that it serialize it back to the proper place.) All I have suggested is that type dependent counting could lessen the burden on applications that don't want to count all possible changes, opening up the potential for different levels of change tracking. Otherwise, we are going to have to define all the elements that are counting for addressing purposes and every application will have to count the same elements. What if I want to count <draw:page> and you do not? How does that impact our respective counting of elements? Thanks for the Apache OpenOffice comments! I need to look more closely at several implementations on CT and other issues. Hope you are at the start of a great weekend! Patrick > > > Mit freundlichen Grüßen / Best regards Oliver-Rainer Wittmann > > -- > Advisory Software Engineer > ---------------------------------------------------------------------- > --------------------------------------------------------------------- > > IBM Deutschland > Beim Strohhause 17 > 20097 Hamburg > Phone: +49-40-6389-1415 > E-Mail: orwitt@de.ibm.com > ---------------------------------------------------------------------- > --------------------------------------------------------------------- > > IBM Deutschland Research & Development GmbH / Vorsitzende des > Aufsichtsrats: Martina Koederitz > Geschäftsführung: Dirk Wittkopp > Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht > Stuttgart, HRB 243294 > > > > From: Svante Schubert <svante.schubert@gmail.com> > To: office-collab@lists.oasis-open.org > Date: 13.09.2012 17:52 > Subject: Re: [office-collab] How do we count? - September 26, 2012 > Sent by: <office-collab@lists.oasis-open.org> > > > > Hi Patrick, > > On 12.09.2012 22:47, Patrick Durusau wrote: > Svante, > > From below: > > > How does omitting the type make counting easier? > > We have less to implement. How does typing help us? > If we omit the type, then we have to all count the same > components from the root. What if my application only > counts text:p and not text:h? If I can count text:p[24] I > can at least apply changes that point to that component. > > I got a solution for clients with different feature set, but I > fear it might take us too far at this stage. May I instead ask > where typing help us in change-tracking scenarios, which could > not be fulfilled without typing? > > There is this quote of Antoine de Saint-Exupery: > "A designer knows he has achieved perfection not when there is > nothing left to add, but when there is nothing left to take > away." > > Ah, but your counting presumes a defined (as yet undefined) counting > system that results in every application getting the same count. > > Yes > Which means they all have to count the *same* components. > > Yes > Sounds like a common data model to me. > > Yes, ODF is the common data model and the components is just an > abstraction from the XML, grouping one ore more XML elements to a > logical unit we call component > What I am suggesting is that if we count types, then if my > application only counts text:p, it can find all changes to the > components for which it offers change tracking. > > Not every application will offer the same level of change tracking. > > So counting should not depend on a universal component counting > system. > > (Unless you think all application should be required to have a common > component counting, whether they offer change tracking for all > defined components or not.) > > Hmmm, what is more, if I only count text:p components, I can append > my changes to the CT file, to be picked up by an application that > offers broader change tracking capabilities. > > Yes? > > You might perhaps solve it with types, but it works IMHO even without > types. > May I draw the answer-this-complex-question-later card? ;) > Hope you are having a great evening! > > Patrick > > Best regards, > Svante > > > On 09/12/2012 03:06 PM, Svante Schubert wrote: > Hi Patrick, > > On 12.09.2012 20:11, Patrick Durusau wrote: > Svante, > > On 09/12/2012 01:24 PM, Svante Schubert wrote: > 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. > > Yes, but here is where the confusion begins. > > There is no specified point for starting the count in > your example other than the first element that appears > being <text:h>. > > That is an impossible starting point for an ODF document > instance (single XML file or package). > > The content of an ODF document is in the content.xml and starts > beyond the office:body child, e.g. for text documents all > children of /office:document-content/office:body/office:text/ > are potential component candidates. > > In our ODF schema there are even defined names as > "office-text-content-prelude" and > "office-text-content-epilogue" > The children of the root of a text document are defined among > <define name="text-content"> > > Yes, the numbers may change after each operation. > > But immediately prior to each operation, there is a > numbering of the components which all applications > loading that document and proceeding to the point prior > to any specified change, agree is the numbering of the > components. > > Each operation results in the next "state" of the > document. That numbers increase/decrease is unremarkable. > > See below for more questions/comments: > > <snip> > > 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. > > > How does omitting the type make counting easier? > > We have less to implement. How does typing help us? > If we omit the type, then we have to all count the same > components from the root. What if my application only > counts text:p and not text:h? If I can count text:p[24] I > can at least apply changes that point to that component. > > I got a solution for clients with different feature set, but I > fear it might take us too far at this stage. May I instead ask > where typing help us in change-tracking scenarios, which could > not be fulfilled without typing? > > There is this quote of Antoine de Saint-Exupery: > "A designer knows he has achieved perfection not when there is > nothing left to add, but when there is nothing left to take > away." > > I don't see the relevance of human readable format for > change tracking. If you want to display paragraph rather > than text:p, be my guest. ;-) > > 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. > > > Don't misuse the concept of "root element." It is well > defined in XML and <text:p> in ODF is not a root element. > There is no misuse, there are just two kind of roots. One > document root element and a component root element. By default, > I will talk about component root elements. > > I suppose an additional meta question is going to be > deciding on a vocabulary to discuss change tracking. ;-) > ;) > > Hope you are having a great day! > > Patrick > > > 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? ;-) > > > > -- > Patrick Durusau > patrick@durusau.net > Former Chair, V1 - US TAG to JTC 1/SC 34 > Convener, JTC 1/SC 34/WG 3 (Topic Maps) > Editor, OpenDocument Format TC (OASIS), Project Editor > ISO/IEC 26300 > Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) > > Another Word For It (blog): http://tm.durusau.net > Homepage: http://www.durusau.net > Twitter: patrickDurusau > > > -- > Patrick Durusau > patrick@durusau.net > Former Chair, V1 - US TAG to JTC 1/SC 34 > Convener, JTC 1/SC 34/WG 3 (Topic Maps) > Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 > Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) > > Another Word For It (blog): http://tm.durusau.net > Homepage: http://www.durusau.net > Twitter: patrickDurusau > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: > office-collab-help@lists.oasis-open.org > -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]