How do we count? - September 26, 2012

[Patrick Durusau <patrick@durusau.net>]

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