OASIS Open Document Format for Office Applications (OpenDocument) TCIcon indicating the project type

OASIS Open Document Format for Office Applications (OpenDocument) TC

Uploaded image for project: 'OASIS Open Document Format for Office Applications (OpenDocument) TC'
  1. OASIS Open Document Format for Office Applications (OpenDocument) TC
  2. OFFICE-3788

Make xml:ids stable over the lifetime of a document

    Details

    • Proposal:
      Hide

      Amend 19:916 xml:id to add the following:

      The value of an xml:id attribute is preserved over the existence of a document instance.

      The Value for an xml:id attribute is never reused in a document instance.

      The value of an xml:id is: "odf" followed by a unique 32-bit number.

      Show
      Amend 19:916 xml:id to add the following: The value of an xml:id attribute is preserved over the existence of a document instance. The Value for an xml:id attribute is never reused in a document instance. The value of an xml:id is: "odf" followed by a unique 32-bit number.

      Description

      Currently, xml:ids (19:914) are not required to be stable over the lifetime of a document. So long as an application maintains the links established by use of xml:ids and serializes those, it is free to generate or save xml:ids it encounters.

      That approach was adopted before the first TC meeting on 16 December 2002. (https://lists.oasis-open.org/archives/tc-announce/200211/msg00001.html) A few days before that, PC Magazine reported its editor's choice for the year:

      "Dell Dimension 8250 - 2.8-Ghz Pentium 4, 512 RDRAM, 7,210-rpm 200GB hard drive, ATI Radeon 9700 Pro graphics card, DVD-ROM and DVD-RW drives, two USB L1 and six USB 2.0 ports, one FireWire port, 18-inch LCD. (Brown, Bruce. PC Magazine. 12/3/2002, Vol. 21 Issue 21, p102. 9p. 4 Color Photographs, 9 Charts.)"

      As of December, 2011, PC Magazine reported its editor's choice as:

      "HP Pavilion p7-1167cb - 3.1GHz Intel Core i5-2400 processor, 8GB of RAM, 7200-rpm 1TB hard drive, AMD Radeon HD 6450 (512MB) discrete graphics card, DVD+-RW, four USB 2.0 ports, audio-in and -out, a mic jack, Ethernet, and VGA and DVI-D video outputs, 25-inch LCD monitor (HP 2511x). (Shoemaker, Natalie. PC Magazine. Dec2011, Vol. 30 Issue 12, p1-1. 1p.)"

      I suspect this is one of those decisions that was influenced by our appreciation of the hardware capabilities implementers would face while implementing ODF. The change in "average" hardware is enough to merit reconsideration of the stability of xml:ids.

      Benefits from stable xml:ids:

      1) Stable reference points for change tracking
      2) Detection of non-change tracked deletions (operation pointer no longer has a target)
      3) Centralized change tracking (request only operations after timestamp or xml:id sequence)
      4) Changes to changes by different applications detectable but not resolved by ODF.

      Not to mention that stable xml:ids would be an incentive to fix all the referencing in ODF 1.3 to use xml:ids and not names, etc.

      I have proposed using a 32-bit number below as that allows addressing up to 4,294,967,295 items. There is a lot of experience with compressing 32-bit numbers. Should we bump that up to 64? Just to avoid revisiting the issue any time soon?

      I prepended odf to the string to meet the requirements of NCNAME in XML Schema Part 2, Datatypes, http://www.w3.org/TR/xmlschema-2/#ID

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          22 older comments
          Hide
          Permalink
          patrick Patrick Durusau added a comment -

          @Andreas.

          Applications, as per my example document last night, already preserve data across edits. We require that and yet a number of implementations seem to achieve that requirement.

          How are xml:ids any different?

          Preservation is "implementation dependent" on how an implementation persists them. That is the requirement is persistence, how you do that is undefined. Mechanism of persistence is undefined by the standard.

          Do you mean xml:id or preservation of an identifier?

          Show
          patrick Patrick Durusau added a comment - @Andreas. Applications, as per my example document last night, already preserve data across edits. We require that and yet a number of implementations seem to achieve that requirement. How are xml:ids any different? Preservation is "implementation dependent" on how an implementation persists them. That is the requirement is persistence, how you do that is undefined. Mechanism of persistence is undefined by the standard. Do you mean xml:id or preservation of an identifier?
          Hide
          Permalink
          orcmid Dennis Hamilton (Inactive) added a comment -

          @Patrick, Very well, I would say merely that "producers may but need not preserve the same xml:id on elements that persist from consumption to production, so long as references to the element by IDREF continue to agree with the xml:id ID value. The alternative is to leave it the same as OF 1.2 does, which is to say nothing about xml:id ID-value preservation.

          Show
          orcmid Dennis Hamilton (Inactive) added a comment - @Patrick, Very well, I would say merely that "producers may but need not preserve the same xml:id on elements that persist from consumption to production, so long as references to the element by IDREF continue to agree with the xml:id ID value. The alternative is to leave it the same as OF 1.2 does, which is to say nothing about xml:id ID-value preservation.
          Hide
          Permalink
          aguelzow Andreas Guelzow (Inactive) added a comment -

          @Patrick: Are we saying anywhere else that the mechanism that an application chooses to fulfil a requirement of the standard is "implementation dependent"? I thought we used that language only for user visible behaviour.

          Show
          aguelzow Andreas Guelzow (Inactive) added a comment - @Patrick: Are we saying anywhere else that the mechanism that an application chooses to fulfil a requirement of the standard is "implementation dependent"? I thought we used that language only for user visible behaviour.
          Hide
          Permalink
          orcmid Dennis Hamilton (Inactive) added a comment -

          @Andreas, if you read the conformance requirements for ODF Consumers, support for any feature is implementation-dependent. Basically the only requirement is to accept schema-conforming documents. There is no requirement to support any particular features in those documents.

          I don't think there has ever been any consideration of implementation-dependent and implementation-defined provisions with respect to how users become aware of them or even notice, although there surely are ways that an allowed implementation-dependence would become apparent.

          In the case of preservation of xml:id ID values, a failure to preserve them would likely show up in the case of the element being identified via its xml:id in RDF and the document producer preserved but did not coordinate the RDF with the document.

          Users can be aware of URIs that refer into ODF documents via identification of fragment or into [X]HTML into exports of ODF documents, but these cases are not covered by the specification.

          Individual implementations might do something about RDF and HTML Export stability, but what they do for both cases is highly implementation-dependent and there is no basis in the specification for expecting interoperability. I suspect that is a greater issue for RDF parts and for RDFa in the documents than anything else. It is of course the nature of RDF that a producers does not necessarily have a way of determining all of the ways a document element having an xml:id may be the subject of an RDF triple that exists somewhere.

          Show
          orcmid Dennis Hamilton (Inactive) added a comment - @Andreas, if you read the conformance requirements for ODF Consumers, support for any feature is implementation-dependent. Basically the only requirement is to accept schema-conforming documents. There is no requirement to support any particular features in those documents. I don't think there has ever been any consideration of implementation-dependent and implementation-defined provisions with respect to how users become aware of them or even notice, although there surely are ways that an allowed implementation-dependence would become apparent. In the case of preservation of xml:id ID values, a failure to preserve them would likely show up in the case of the element being identified via its xml:id in RDF and the document producer preserved but did not coordinate the RDF with the document. Users can be aware of URIs that refer into ODF documents via identification of fragment or into [X] HTML into exports of ODF documents, but these cases are not covered by the specification. Individual implementations might do something about RDF and HTML Export stability, but what they do for both cases is highly implementation-dependent and there is no basis in the specification for expecting interoperability. I suspect that is a greater issue for RDF parts and for RDFa in the documents than anything else. It is of course the nature of RDF that a producers does not necessarily have a way of determining all of the ways a document element having an xml:id may be the subject of an RDF triple that exists somewhere.
          Hide
          Permalink
          patrick Patrick Durusau added a comment -

          Discussed Oct. 3, 2016 - would introduce a requirement not supported by gnumeric. - quite possibly other ODF applications.

          Lack of fixed ids impacts interoperability.

          XML:IDs could be created only on export - making other applications slower -

          Show
          patrick Patrick Durusau added a comment - Discussed Oct. 3, 2016 - would introduce a requirement not supported by gnumeric. - quite possibly other ODF applications. Lack of fixed ids impacts interoperability. XML:IDs could be created only on export - making other applications slower -

            People

            • Assignee:
              patrick Patrick Durusau
              Reporter:
              patrick Patrick Durusau
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: