OASIS Open Document Format for Office Applications (OpenDocument) TC
  1. OASIS Open Document Format for Office Applications (OpenDocument) TC
  2. OFFICE-3693

Public Comment: (Ed) 3.10.2 <config:config-item-set> [ODF 1.2 Part 1, Public ReviewDraft 03 of Jan 19th 2011]

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: ODF 1.2 CD 07
    • Fix Version/s: ODF 1.3
    • Component/s: General, Part 1 (Schema)
    • Labels:
      None

      Description

      Copied from office-comment list

      Original author: Jesper Lund Stocholm <4a4553504552@gmail.com>
      Original date: 4 May 2011 07:07:18 -0000
      Original URL: http://lists.oasis-open.org/archives/office-comment/201105/msg00001.html

        Activity

        Hide
        Rob Weir added a comment -
        The role of the standard is to define requirements.

        If we desire to describe implications of the requirements on interoperability and provide additional guidance on how specification features are best used in situations where interoperability concerns dominate, then that a subject for another document, in another committee. The OASIS ODF Interoperability and Conformance TC works on those topics, including guidelines for implementors and users.

        However, if there were ambiguity or uncertainty about what this clause says, in terms of a requirement, then that would be something for this TC to deal with. But the public comment does not raise an issue of that nature.

        I recommend close with no action.

        Wearing my OIC TC member hat, I think the interoperability advice would be quite straightforward. Settings stored using this mechanism might not be understood by other editors and might be stripped from documents when other editors save your document. Implementations should be sensitive to the interoperability implications of these possibilities.

        This is one of many things implementors (and users) who desire high levels of interoperability should think about. The OIC TC is where such discussions occur.
        Show
        Rob Weir added a comment - The role of the standard is to define requirements. If we desire to describe implications of the requirements on interoperability and provide additional guidance on how specification features are best used in situations where interoperability concerns dominate, then that a subject for another document, in another committee. The OASIS ODF Interoperability and Conformance TC works on those topics, including guidelines for implementors and users. However, if there were ambiguity or uncertainty about what this clause says, in terms of a requirement, then that would be something for this TC to deal with. But the public comment does not raise an issue of that nature. I recommend close with no action. Wearing my OIC TC member hat, I think the interoperability advice would be quite straightforward. Settings stored using this mechanism might not be understood by other editors and might be stripped from documents when other editors save your document. Implementations should be sensitive to the interoperability implications of these possibilities. This is one of many things implementors (and users) who desire high levels of interoperability should think about. The OIC TC is where such discussions occur.
        Hide
        Dennis Hamilton (Inactive) added a comment -
        I agree completely with this assessment and I think it is perfect for an advisory at the OIC TC.

        [I went and looked at CS01 on this and there is a peculiar statement in config:name that could use a note too, and that could be illustrated in an advisory.

        I was looking for benign settings that a product could retain about a document. One would be the preferred spell-checking dictionary (which could be user specific), which actually doesn't effect behavior with regard to the document directly, and another could be the automatic-hyphenation rules, if any, which would impact layout flow but are within the variability of the specification (I think).
        Show
        Dennis Hamilton (Inactive) added a comment - I agree completely with this assessment and I think it is perfect for an advisory at the OIC TC. [I went and looked at CS01 on this and there is a peculiar statement in config:name that could use a note too, and that could be illustrated in an advisory. I was looking for benign settings that a product could retain about a document. One would be the preferred spell-checking dictionary (which could be user specific), which actually doesn't effect behavior with regard to the document directly, and another could be the automatic-hyphenation rules, if any, which would impact layout flow but are within the variability of the specification (I think).
        Hide
        Rob Weir added a comment -
        Two things:

        1) What does the standard allow?

        and

        2) What breaks interoperability?

        To me it is clear that config settings, used in a conforming way, could break interoperability. For example, you could have a config settings that says, "In the absence of a default font definition, use Zapf Dingbats 4 pt, green text on a purple background."

        The interesting thing, however, about that case, is that a conforming implementation may have this behavior even without config settings. It could just be the application's hard-coded default setting. So config settings don't enable new ways of breaking interoperability. They merely give another way for an implementation to control the use of any conforming, non-interoperable behavior they already support.

        Of course, I'd love to have fewer non-interoperable behaviors. But the way we address that in the spec is by adding additional requirements on the underlying behaviors, e.g., a requirement on default text styles. You don't get far by trying to restrict where the document these settings are stored.
        Show
        Rob Weir added a comment - Two things: 1) What does the standard allow? and 2) What breaks interoperability? To me it is clear that config settings, used in a conforming way, could break interoperability. For example, you could have a config settings that says, "In the absence of a default font definition, use Zapf Dingbats 4 pt, green text on a purple background." The interesting thing, however, about that case, is that a conforming implementation may have this behavior even without config settings. It could just be the application's hard-coded default setting. So config settings don't enable new ways of breaking interoperability. They merely give another way for an implementation to control the use of any conforming, non-interoperable behavior they already support. Of course, I'd love to have fewer non-interoperable behaviors. But the way we address that in the spec is by adding additional requirements on the underlying behaviors, e.g., a requirement on default text styles. You don't get far by trying to restrict where the document these settings are stored.
        Hide
        Regina Henschel added a comment -
        This issue should be handled together with
        https://issues.oasis-open.org/browse/OFFICE-2072
        Public Comment: ODF 1.2 CD03 2.11.2 <config:config-item-set>
        Show
        Regina Henschel added a comment - This issue should be handled together with https://issues.oasis-open.org/browse/OFFICE-2072 Public Comment: ODF 1.2 CD03 2.11.2 <config:config-item-set>
        Hide
        Patrick Durusau added a comment -
        Capabilties defined by ODF must be implemented in ODF and not in settings.
        Show
        Patrick Durusau added a comment - Capabilties defined by ODF must be implemented in ODF and not in settings.
        Hide
        Patrick Durusau added a comment -
        As per 8 Aug. 2016
        Show
        Patrick Durusau added a comment - As per 8 Aug. 2016

          People

          • Assignee:
            Unassigned
            Reporter:
            Rob Weir
          • Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: