Svante,
Yes, please have a answer-this-complex-question-later card. ;-)
But do note that I firmly disagree that ODF is a common data model.
It is a common serialization for any number of data models.
I am using "data model" to mean my internal representation once I
parse the XML.
I could have a simple tree structure, I could have a DAG, I could
have a table, and all of them function equally well for particular
applications.
What is required is that when I serialize the in memory
representation (my meaning of data model), is that it meet all the
requirements of the ODF format.
That is we specify a serialization of changes against that common
serialization so that when we exchange that representation,
applications reach a common state of the document with regard to
changes. What data model the applications are following isn't
relevant at that point.
Yes?
Hope you are having a great week!
Patrick
PS: A data model I would like to see is a graph that reports a
document as a sub-graph of a much larger graph, so that components
of "a" document are not repeated. Common components are reported out
whenever they form part of a sub-graph that is a document. Would
make collection indexing, retrieval and transclusion quite natural.
(As opposed to the unnatural operations they are now.)
On 09/13/2012 11:51 AM, Svante Schubert
wrote:
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
--
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
|