Hi Michael,
Good points from you and Rob. Regarding submitting an alternative proposal, we €™ll consider this possibility after the requirements phase is completed and the SC has made decisions on the scope of what €™s needed. AS Rob points out, there are two obvious paths forward at the moment (refining the DeltaXML proposal or refining the existing text in ODF 1.2), and I €™d say it €™s not clear yet (to me, anyway) whether the best solution will be one of those paths or a third rail. Er, path. :)
Regards,
Doug
From: Michael Brauer [ mailto:
michael.brauer@oracle.com ]
Sent: Tuesday, January 25, 2011 7:42 AM
To: Doug Mahugh
Cc:
robert_weir@us.ibm.com;
office-collab@lists.oasis-open.org; Tristan Mitchell
Subject: Re: [office-collab] Wiki updates: Requirements and Use Cases
Hi Doug,
I agree to Rob. So, we have the proposal from DeltaXML. My point was that I find it obvious and reasonable that those TC members who have worked out this proposal check whether it meets the requirements that the SC defines, and that they if required adapt it. I would find it strange if they stop any work on their proposal until the SC has defined all requirements.
But of course, the fact that TC members work on a proposal does not imply that this proposal is already accepted, or that the TC may not get alternative proposals. However, if you intent to submit an alternative proposal, it would be fair if you let the SC know that.
Best regards
Michael
On 24.01.2011 19:15,
robert_weir@us.ibm.com wrote:
Hi Doug,
If you have a concrete proposal, feel free to make it. Otherwise I think
it is natural that we consider the two specifications that we have in
front of us:
1) The existing ODF 1.2 change tracking specification (essentially our
default position, if we do nothing)
2) The deltaXML proposal
Other proposals are welcome, of course.
In parallel we're also gathering requirements and use cases:
http://wiki.oasis-open.org/office/Advanced%20Document%20Collaboration I think your feedback so far on the high-level ramifications of a
particular model is valuable. It is good to separate the important model
issues from the issues of mere notation. So I think we're having the
right kinds of discussions.
I know that we're not following a pure "waterfall model" development, but
I think there is some value to iteration, of looking at requirements,
specification and implementation together and iterating until you've
satisfied all constraints. Such a loosely-structured approach might not
scale to extremely large efforts, but I'm not overly concerned with it
being used for this SC's modest efforts.
Before you joined the TC, we had a similar situation with OpenFormula. A
3rd party group -- the Open Document Fellowship -- noting the lack of a
detailed formula specification in ODF 1.0, drafted one on their own. They
contributed the draft to the ODF TC and some of their members joined as
well. We elected the author of that specification as SC Chair. We worked
on the draft in a SC until it was ready for inclusion in ODF 1.2. The end
result appears to have satisfied all. We're we appreciative of the
specification contributed by the Fellowship? Yes. But did we take it
as-is and refuse to change it? Hell, no. We spent a couple of years
working on the draft, including work to make sure the spec was
implementable by legacy applications. I'm hoping we can do something
similar for change tracking, albeit at a faster pace, as befits a much
shorter specification.
Regards,
-Rob
Doug Mahugh <
Doug.Mahugh@microsoft.com> wrote on 01/24/2011 12:03:15 PM:
Michael,
Isn't this just another requirement. Something like: It must be
possible to accept or reject change in any order unless a change
depends on another one which first would have to be accepted or
rejected? I don't know if the current proposal supports that, but if
not, why not just modify the proposal so that it supports this
requirement, too? During the development of a specification, it may
of course happen that a particular requirement is not met initially.
But I think that does not mean that we need to start from scratch again.
I agree that this should be a requirement, but I don €™t understand
the perspective that including such a requirement would be starting
from scratch €œagain. € Isn €™t that where we €™re at in the process, at
the initial requirements-gathering stage? Your comment seems to
imply that there has already been a requirements-gathering process,
but I €™m not aware of any such process that has taken place in this
SC, the ODF TC, or any other open and public group. You also mention
the concept of modifying the DeltaXML proposal, but that seems to
presume that this SC is actively working from that proposal and
massaging it into our final recommendation. If that €™s your view,
it €™s not clear to me how or when we arrived at that position.
When this SC was formed, the Statement of Purpose asked us to
€œprepare a draft specification of a markup vocabulary that can
accurately describe any incremental change to the content and
structure of documents, € and the first deliverable of the SC was to
be "a draft specification for change tracking, including Relax NG
schema." So I €™m assuming that this is still our top priority, and
not something that has already been handled for us by a private
group prior to the creation of the SC.
I also recall this exchange between Cherie and Rob during the
initial discussion of the scope of the SC:
Cherie:
The first purpose of any subcommittee created to do this work,
however, should be to examine the all the practicable options
available for creating robust change
tracking in ODF. That includes not simply looking at the DeltaXML
proposal and massaging it, but also looking at other alternatives
including reworking the existing
ODF change tracking (as some TC members have suggested), looking
into change tracking methods used in other standards, and starting
from scratch to create a
change tracking that is targeted to the ODF standard and focused
on the business needs of ODF users.
Rob:
DeltaXML is not mentioned at all in the proposal [for creation of
this SC]. It talks of the need to "investigate opportunities and
draft enhancements to ODF".
So I think that is sufficiently open to allow consideration of all
options.
I continue to believe that the proposal this SC develops should be
something created in response to the requirements the SC gathers.
You said €œeven if we would have a complete list of requirements, at
some point in time someone would have to start with an initial
proposal," and I agree, but I think the development of such a
proposal should take place after the requirements-gathering phase,
and not before.
Regards,
Doug
From: Michael Brauer [ mailto:
michael.brauer@oracle.com ]
Sent: Monday, January 24, 2011 5:38 AM
To: Doug Mahugh
Cc: Tristan Mitchell;
office-collab@lists.oasis-open.org Subject: Re: [office-collab] Wiki updates: Requirements and Use Cases
Hi Doug,
On 21.01.2011 21:28, Doug Mahugh wrote:
Hi Tristan,
Thanks for the feedback. I generally agree, although I think we're
still looking at the implementation work differently.
I agree that implementation can be a useful step in analyzing the
viability of a proposal. But this SC has never discussed the various
architectural decisions that went into the DeltaXML proposal, and I
think that we should build consensus on those sorts of high-level
issues first, before we consider the details of possible prototype
implementations.
For example, the CT stack concept allows only for accepting or
rejecting changes in the order that they were made in the document.
But in my own experience of how people use change tracking
functionality, it is more common to go through the document and
accept or reject individual changes in a different order -- perhaps
in the order they appear within the flow of the document, or perhaps
some other order dictated by the specific collaboration task at
hand. Some changes really do stack (deleting text that was
previously inserted) but that €™s an application UI issue, not a file
format issue. Forcing the user to accept/reject changes in a
particular order (which is essentially random, determined by the
order in which collaborators happened to edit the document) seems to
make change tracking more akin to a revision history, with fixed
versions of the document available from specific points in time.
Isn't this just another requirement. Something like: It must be
possible to accept or reject change in any order unless a change
depends on another one which first would have to be accepted or
rejected?
I don't know if the current proposal supports that, but if not, why
not just modify the proposal so that it supports this requirement,
too? During the development of a specification, it may of course
happen that a particular requirement is not met initially. But I
think that does not mean that we need to start from scratch again.
Actually, even if we would have a complete list of requirements, at
some point in time someone would have to start with an initial
proposal, would have to check whether it meats all requirements, and
if not, would have to modify it (or think about the importance of
the requirement) until it meets all requirements.
Having that said: The current proposal seems provide a very solid
basis for our discussion, and I'm glad that we received a proposal
which contains already as much details as the current proposal does.
If we have implementers building change-tracking functionality that
doesn't allow for the same sorts of flexibility that users have come
to expect from alternative change-tracking approaches, I think that
starts to limit the SC's options in the future. We could later
decide that arbitrary ordering of accept/reject operations is
allowed, of course, but that feels to me like a fundamental aspect
of the DeltaXML proposal, and I'd imagine that implementers would
find it difficult to make such a change without re-doing a lot of their
work.
We had a similar discussion in the main TC recently. Actually,
whoever implements a proposal or draft does that on its own risk,
and the existence of such an implementation of course does not
provide that argument that a specification must not be changed. But
implementations of proposals actually help us to verify that a
particular proposal does work in practice. I'm therefore glad hat
there are volunteers for early implementations of the change
tracking proposal.
Best regards
Michael
I just offer that as one of many examples of philosophical/
architectural issues that are built into the DeltaXML proposal, may
have long-term repercussions, and have never been discussed or
analyzed by this SC. I think we need to have those discussions
first, in keeping with Requirement 3.3 (high degree of consensus).
Then, after we have reached consensus on a proposed approach, test
implementations could be a useful step to help analyze the viability
of that proposal.
- Doug
-----Original Message-----
From: Tristan Mitchell [ mailto:
tristan.mitchell@deltaxml.com ]
Sent: Friday, January 21, 2011 3:16 AM
To: Doug Mahugh
Cc:
office-collab@lists.oasis-open.org Subject: Re: [office-collab] Wiki updates: Requirements and Use Cases
Hi Doug,
Thanks for your comments on this, some very useful points. I have
responded inline below.
On 21 Jan 2011, at 00:00, Doug Mahugh wrote:
I €™ve reviewed the list of requirements and use cases on the wiki,
and it looks like a great start. Thanks for pulling this together,
Robin.
Regarding use cases, the list is quite comprehensive and seems close
to complete. One thing I did was to compare that list to the various
things that ISO/IEC 29500 change tracking covers, and they line up
pretty well but there are a few areas that may be worth adding to
our list. One broad general category would be changes to document
layout, as opposed to document content. For example, changes to a
document €™s page size, orientation, or number of columns (Part 1,
Section 17.13.5.32 sectPrChange), or changes to a table €™s properties
such as column width (Part 1, Section 17.13.5.33 tblGridChange).
These sorts of changes can have a significant effect on the user €™s
perception of a document even if the document text has not changed,
and they €™re the sorts of things that people often tweak in multi-
user collaborative editing scenarios, so it would be useful to be
able to manage those changes in the same way that content changes are
managed.
Yes, I think that the scope for changes needs to be broader than
just document content. Adding layout-specific use cases is a good
idea, I will add them shortly.
Another observation on the use cases list is that it €™s currently a
list of specific types of content that could be inserted, deleted or
moved (which is an important first step), but I think it would be
useful to think about some of the ways these atomic operations are
typically combined in collaborative editing scenarios, and how
people tend to work with changes from multiple users. For example, a
common scenario might be for user A to insert a paragraph, users B
and C make changes to that paragraph, and then the editor/originator
of the document might want to include A €™s paragraph with some of C €™s
changes and none of B €™s changes. (We all know people like B. J) I
don €™t have a specific proposal for how we capture such multi-step
scenarios, but I assume we €™d all agree that we want to end up with
an approach that allows for the most common ones.
I agree that this is something that needs consideration and
discussion although I'm not sure that it falls within the work of
designing a change-tracking format. As long as the changes (and the
relevant information such as editor, time etc) are recorded, the
processing of the changes to form the next version of the document
is surely the responsibility of an application, not the format itself.
A few thoughts on the Requirements page €¦
One thing that struck me was the combination of €œ1.5 Can convert
from existing change tracking mechanism to new one € and €œ2.2
Interoperability with other formats. € These two requirements may be
at odds with one another: is it actually possible to define change
tracking in a way that maps to the existing approach as well as the
approach used in OXML, for example? I think that we should take into
consideration the magnitude of existing usage of ODF and OXML change
tracking, and prioritize accordingly, in the interest of maximizing
the opportunities for use of the new approach we €™re designing. I €™m
sure there are other perspectives on this, but it €™s probably a
conversation worth having.
As far as requirement 1.5 goes, I think this would only be a one-way
conversion i.e. converting from the existing change-tracking
mechanism to the new one. The resultant document would of course
have the same limitations as the existing change-tracking format in
that it would only represent those changes that can currently be
tracked. Converting back the other way is not necessary and indeed
need not be possible. The conversion would either be performed via
an application's internal model in a load-save cycle and/or could be
written as an XSLT script to generate the new format. If we limit
conversion to this direction only, I see no reason why
interoperability with other formats would need to be compromised.
€œ2.4 Track all possible types of change € is a very broad statement,
and we €™ve already discussed some exceptions to it (such as the
issues surrounding cached and recalculated values in spreadsheet
formulas, for example). I think we should modify this requirement to
something like €œTrack appropriate types of changes € or something
similar.
I agree that we already have some cases of information that should
not be tracked but this doesn't mean that it can't be. A generic XML
change-tracking solution would have the capability of tracking any
kind of XML change. An ODF specific change-tracking format could
then take the generic format and limit it only to those places
relevant to ODF i.e. not tracking cached values etc.
One potential stumbling block here (already pointed out by Rob Weir)
is tracking changes in referenced objects such as images. It would
be possible (at least in an ODF Zip package) for the XML pointing to
an image file to remain precisely the same but for the actual image
to be different. We do need to consider how this type of change
would be tracked. Note that in the flat single XML file version of
ODF, the image would be represented within the XML and changes to
the encoded value could be recorded.
€œ2.6 Proven implementations € seems a good requirement once we decide
upon a specific approach, but I think we should be clear that we €™re
designing an approach first, and then we €™ll need to see
implementations of it. I €™m a little concerned by the fact that some
SC members appear to be actively implementing the DeltaXML proposal
(per Ben €™s questions) or considering the details of how to do so
(per Frank €™s comments). Would everyone agree that we should not be
rushing to implement a specific proposal prior to this SC agreeing
upon a design? If so, then I think we need to work through the high-
level concepts first, and then look at how various approaches
(including the DeltaXML proposal) can support our collective vision
of how ODF change tracking should work. I €™d hate to see us start
making design compromises in the interest of compatibility with a
specific proposal that we €™ve not yet analyzed, discussed, or agreed
upon.
I understand your concerns here but I think that implementation is a
useful step in analysing the viability of a proposal. There are some
XSLT scripts for the DeltaXML proposal that show that for a tracked
sequence of changes it is possible to get back to any of the
intermediate document versions within that sequence but these only
go part way to proving it as a solution. Determining whether the
proposal can be implemented in an application using an internal
model will be very useful in deciding whether to use it as the
final solution or not.
€œ3.1 Future-proof € is an appealing concept, but the concept of
assuring that no additional work would be needed on change tracking
when new ODF features are added sounds problematic to me. Can we
really decide, in this SC, that all of ODF €™s future evolution will
be constrained by the design we come up with for change tracking in
ODF v-Next? Would we even want to decide this? I think that we (and
all other stakeholders in ODF maintenance) are unlikely to adhere to
such a constraint, and for that reason I €™d rather say €œminimal
additional work needed € instead of €œno additional work needed. €
Again I think that a generic XML change-tracking solution would
allow us to be future-proof. If any XML change could be represented
then any new ODF constructs added in the future could be tracked
without any modification to the change-tracking format itself.
However, it may be necessary to consider the change-tracking format
when specifying new elements, particularly if the new constructs are
items that should not be tracked (e.g. calculated values etc).
Regards,
Tristan
What do others think?
Regards,
Doug
-----Original Message-----
From: Robin LaFontaine [ mailto:
robin.lafontaine@deltaxml.com ]
Sent: Wednesday, January 19, 2011 4:02 AM
To:
office-collab@lists.oasis-open.org Subject: [office-collab] Wiki updates: Requirements and Use Cases
Wiki updates: Requirements and Use Cases
We have updated the wiki (1) to include a summary of the
Requirements (derived from (2)) and also all the Use Cases that we
have to date.
The wiki provides a list of all the Use Cases, and the actual files
are posted in a zip file in a new Use Cases folder in the documents
section (3). For each use case, the zip file contains the ODT
documents. In most cases this is two documents ('before change' and
'after change'), but for some use cases it is more than two. The
document samples contain text to describe the change, so they are
intended to be self-documenting.
The Requirements and the Use Cases both have reference numbers
against each item, to make it easier for e-mail discussion on any
individual item. The zip file for the Use Cases has also been
annotated with the numbers for easier cross-referencing.
The Use Cases zip file does not contain any worked solutions, but if
you want to access the original submission which includes worked
solutions and code to demonstrate that they work, then this is in
the office comments e-mail (4). This does not contain the new Uses
Cases I ('Other'
section).
In addition to the Use Cases above, we also have Rob Weir's comments
in his e-mail dated 6th January 2011 (5), and I will reply to that
separately because I think there are some points that need further
discussion.
If you are aware of any other use cases or requirements, please add
these to the wiki as soon as possible.
(1) Wiki with Requirements and Use Cases:
http://wiki.oasis-open.org/office/Advanced%20Document%20Collaboration (2) Original ADC Requirements Summary email:
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archi ves/201012/msg00019.html
(3) Documents including Use Cases zip:
http://www.oasis-open.org/apps/org/workgroup/office-collab/documents.p hp
(4) Original submission with proposed solutions
http://lists.oasis-open.org/archives/office-comment/201007/msg00011.ht ml
(5) Use cases email from Rob Weir
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archi ves/201101/msg00000.html
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML"
T: +44 1684 592 144 E:
robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --
Tristan Mitchell, DeltaXML Ltd "Change control for XML"
T: +44 1684 869 035 E:
tristan.mitchell@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
--
Michael Brauer Oracle Office Development
Phone: +49 40 23646 500
Oracle Office Global Business Unit
ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
Oracle is committed to developing practices and products that help
protect the environment
--
Michael Brauer Oracle Office Development
Phone: +49 40 23646 500
Oracle Office Global Business Unit
ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
Oracle is committed to developing practices and products that help protect the environment