OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[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


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.



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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]