Ben,
Sounds good re numeric IDs, thanks.
A change-id attribute is not intended as human-readable. I think if we
need a human-readable then this should not be in an attribute but as
PCDATA in markup (but that is just my opinion!), and this was the
intention of the delta:change-log as you suggest. We need more precise
descriptions of these elements so that the intention is clearer.
I hope this answers your question, sorry about delay in responding.
Robin
monkeyiq wrote:
1292311541.7392.138.camel@alkid.localdomain"
type="cite">
Ah excellent point re numeric IDs. For now I'll just assume the
change-ids are arbitrary XML attributes and reassign numeric monotonic
numbers on document load based on the revision time from the change-info
element.
Should the change-id attribute used in the delta:change-id be taken as
the human readable description of this change ID to show the user or
should we use an attribute inside delta:change-info (delta:change-log in
the below example) for this human targeted information?
If we want to have an explicit attribute for the human description,
perhaps we should update section 5 of odf-track-changes.odt to include
this in the example too? Sorry if this is already the case but I missed
it :/
On Mon, 2010-12-13 at 11:27 +0000, Robin LaFontaine wrote:
Ben,
I am certainly in favour of making things easier for implementers.
However, there are dangers in overloading the ID to effectively contain
some timing information. For example, when we do a comparison between
two documents, we may list the changes as track changes but we have no
information on when these were made, so by default they are all given
the same timestamp. However, their IDs would be different, in order that
the changes can be accepted or rejected independently.
There is, as you say, another way of finding out this information.
Regards,
Robin
monkeyiq wrote:
Hi,
While reading the track changes spec and hacking support for it into
Abiword, I've noticed a few things which might make life easier for
other implementers if they were accommodated in the spec rather than in
each application implementing it.
There are cases such as this one where the existing code I am working
with uses numerical IDs. So I can either hack a lookup map to translate
string<->id or have the spec enforce that ids are as described below and
perhaps other applications can rely on that too.
Explicitly I refer to the idrefs for Change IDs.
Looking at the Change Transaction (CT) Structure section of the document
referenced in the subject line, the form of a changeID is left
reasonably open. In abiword, a revision (or change id) can have a user
defined name and gets an internal "ID" which is a monotonically
increasing integer.
<delta:tracked-changes>
<delta:change-transaction delta:change-id="1">
<delta:change-info>
<dc:creator>Ben Martin</dc:creator>
<dc:date>2010-12-09T02:34:50</dc:date>
<delta:xvers>0</delta:xvers>
<delta:change-log>All your base are belong...</delta:change-log>
</delta:change-info>
</delta:change-transaction>
<delta:change-transaction delta:change-id="2">
...
I am using the change-log element for the user's description of a
revision at the moment, though a name field might be more appropriate.
Having monotonically increasing integers for the change-id references
has the advantage of being short, not subject to user input in the
change-id attribute, and obviously if idn < idj then it is an earlier
revision.
I am wondering if such requirements for the change-id would be
appropriate in the spec itself so that all applications can rely on
this. Obviously one can do a
change-transaction-lookup-dc-date-time_t("ct3")
< change-transaction-lookup-dc-date-time_t("foo7")
to find out if ct3 is older than foo7 using the existing spec, so it
becomes a question of if folks think using numeric IDs would make their
implementation easier too.
---------------------------------------------------------------------
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
--
-- -----------------------------------------------------------------
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
|