office-collab — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Counting in Access Paths
I'm having a terminology problem here. As far as I'm concerned, s="/2/10" and e="/3/18" are absolute addresses. Hierarchical, but absolute, not unlike in absolute URLs. It's more brittle than in a URL because it is based on counted position, not on labeled hierarchy nodes. That means insertion and deletion of siblings at every level requires these references to be repaired. That's scary. On the other hand, to use an existing example, xml:id="ct270478544" establishes a *fixed* identifier, but it does not rely on fixed locations. So wherever a text:change-id="ct270478544" happens to refer to it, the connection is maintained no matter what kind of movement happens on the paths between the two. It is true that in the specific case of the ODF 1.2 use of this device, the <text:changed-region> element is referenced from the content where it is applicable, not the reverse. That seems like a good choice to me, considering that it is the reference from the content that makes examination of the <text:changed-region> of any concern. This also allows the <text:changed-region> material to be output in front of the content, so it can all be indexed before the in-text references occur in the datastream.
Does not the MCT use of these rigid absolute paths require that the document be serialized before the tracking information can be serialized? And for a consumer presenting the content, is it necessary to find the relevant change-tracking information by some synchronization method? My concern is that it is impossible to detect when synchronization has been broken. Everything has to be absolutely perfect and there is no way to touch a change-tracked document without having to adjust all of the tracking locations. That's a considerable burden. I am only addressing the cross-identification approach here. It appears that ODF CT does this in a more robust way; I don't see why MCT can't be made at least as resilient.
I think there does need to be a stretchy way to connect between tracked details and the point of change. An xml:id ID value and a corresponding IDREF attribute value do this perfectly for XML-modeled persistent document formats. And this kind of support already has to exist in ODF-based processors simply because of the many ways that cross-referencing is handled by identifiers of some type, including IRIs that refer into package parts by fragment identifiers.
- Dennis
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]