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