jsr-283
  1. jsr-283
  2. JSR_283-435

Decision F2F Basel 07: new compliance levels

    Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: general
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      435

      Description

      at the last f2f in basel we decided to have the following compliance
      levels. this issue serves as reminder only as at least the source is
      not yet aligned with that.

      New Compliance Structure (copied from findings document).
      ------------------------------------------------------------------

      Level 1

      o Read
      o Export
      o Query (without join)

      Level 2

      o All level 1 features
      o Write
      o Import
      o Simple Versioning
      o Access Control Management (policies only)
      o Locking
      o Default Location (Unfiled)
      o Lifecycle Management

      Options (individually optional on top of level 2)

      o Full Versioning (consists of all of the following)
      > Full Versioning features
      > Versioning Additions (**)
      > Workspace Management
      > Multiple Workspaces
      > Update, Clone and cross-workspace Copy
      o Shareable Nodes (Multi-filing)
      o Retention, Hold, Access Control with ACEs
      o Simple Node Type Management
      o Complete Node type Management (includes simple NTM)
      o Joins in query
      o Transactions
      o Observation (includes primitive events,
      method events and journaled observation)

      i'd say: ac discovery and policies as it is defined in the refactored spec.
      (**) i guess 'versioning additions' meant to be activities and baselines.

        Issue Links

          Activity

          Hide
          anchela added a comment -

          (improve subject)

          Show
          anchela added a comment - (improve subject)
          Hide
          Peeter Piegaze added a comment -
              • Issue 345 has been marked as a duplicate of this issue. ***
          Show
          Peeter Piegaze added a comment - Issue 345 has been marked as a duplicate of this issue. ***
          Hide
          Peeter Piegaze added a comment -

          At the phone conference of 2008.06.23 [1] we decided to adopt the proposed compliance model [2],
          which defines a system for fine-grained testing of repository features.

          I have added a new compliance section and placed the list of descriptors and feature-bound node types
          in the appendix (we can remove this if the Javadoc is deemed to be sufficient).

          Since the new proposal defines new descriptor get methods I assume we intend to deprecate the old
          ones. Is this correct?

          As for the descriptor constants, some are carried forward from JSR-170, while others are new. The new
          ones, according the proposal, will have values in Java package form while the old ones stay the same. Is
          that right?

          For those constants not carried forward (though still present in the src) I assume that
          isStandardDescriptor should return false and getDescriptorValue should return null. Correct?

          [1] https://jsr-283.dev.java.net/source/browse/jsr-283/admin/phone-conf/jsr-283-eg-
          20080623.ppt?rev=1.1&view=markup

          [2] https://jsr-283.dev.java.net/source/browse/jsr-
          283/docs/new/Proposed%20Compliance%20Model%20for%20JSR-283.doc?
          rev=1.1&sortby=date&view=markup

          Show
          Peeter Piegaze added a comment - At the phone conference of 2008.06.23 [1] we decided to adopt the proposed compliance model [2] , which defines a system for fine-grained testing of repository features. I have added a new compliance section and placed the list of descriptors and feature-bound node types in the appendix (we can remove this if the Javadoc is deemed to be sufficient). Since the new proposal defines new descriptor get methods I assume we intend to deprecate the old ones. Is this correct? As for the descriptor constants, some are carried forward from JSR-170, while others are new. The new ones, according the proposal, will have values in Java package form while the old ones stay the same. Is that right? For those constants not carried forward (though still present in the src) I assume that isStandardDescriptor should return false and getDescriptorValue should return null. Correct? [1] https://jsr-283.dev.java.net/source/browse/jsr-283/admin/phone-conf/jsr-283-eg- 20080623.ppt?rev=1.1&view=markup [2] https://jsr-283.dev.java.net/source/browse/jsr- 283/docs/new/Proposed%20Compliance%20Model%20for%20JSR-283.doc? rev=1.1&sortby=date&view=markup
          Hide
          dpitfiel added a comment -

          > Since the new proposal defines new descriptor get methods I
          > assume we intend to deprecate the old ones. Is this correct?

          The proposal adds the methods:

          public Value getDescriptorValue(String);
          public Value[] getDescriptorValues(String); // for MV descriptors

          The existing methods are:

          public String[] getDescriptorKeys();
          public String getDescriptor(String);

          I suggest not deprecating either of the old methods. There is no replacement
          for the first, getDescriptorKeys. The second, getDescriptor, could be
          deprecated since it becomes just a convenience method on top of
          getDescriptorValue – but since it already exists, I'd suggest not deprecating
          it (even though I'm no fan of adding convenience methods).

          > As for the descriptor constants, some are carried forward from
          > JSR-170, while others are new. The new ones, according the proposal,
          > will have values in Java package form while the old ones stay the
          > same. Is that right?

          For repository-specific descriptors, the proposal recommendeds package-style
          naming.

          For standard descriptors, the intent was to follow the existing patterns for
          both the names and the values of the constants, since quite a few JSR-170
          descriptors are being carried forward.

          > For those constants not carried forward (though still present in the
          > src) I assume that isStandardDescriptor should return false and
          > getDescriptorValue should return null. Correct?

          I'd suggest isStandardDescriptor return true, getDescriptor return a value with
          the same semantics as JSR-170, and getDescriptorValue return the same thing but
          as a Value instead of a String.

          Here are the JSR-170 descriptors not mentioned in the proposal, and how I
          suggest we treat each.

          REP_NAME_DESC
          REP_VENDOR_DESC
          REP_VENDOR_URL_DESC
          REP_VERSION_DESC
          SPEC_NAME_DESC
          SPEC_VERSION_DESC
          not compliance related; no change from JSR-170

          OPTION_QUERY_SQL_SUPPORTED
          constant is deprecated;
          true iff the (deprecated) JSR-170 SQL query language supported

          QUERY_XPATH_DOC_ORDER
          QUERY_XPATH_POS_INDEX
          constant is deprecated;
          false unless the (deprecated) JSR-170 XPath query language supported;
          if supported, same semantics as JSR-170

          LEVEL_1_SUPPORTED
          constant is deprecated;
          true iff
          OPTION_XML_EXPORT_SUPPORTED = true, and
          QUERY_LANGUAGES is non-zero length
          (this definition gives the descriptor the same semantics as in JSR-170)

          LEVEL_2_SUPPORTED
          constant is deprecated;
          true iff
          LEVEL_1_SUPPORTED = true, and
          WRITE_SUPPORTED = true, and
          OPTION_XML_IMPORT_SUPPORTED = true
          (this definition gives the descriptor the same semantics as in JSR-170)

          Show
          dpitfiel added a comment - > Since the new proposal defines new descriptor get methods I > assume we intend to deprecate the old ones. Is this correct? The proposal adds the methods: public Value getDescriptorValue(String); public Value[] getDescriptorValues(String); // for MV descriptors The existing methods are: public String[] getDescriptorKeys(); public String getDescriptor(String); I suggest not deprecating either of the old methods. There is no replacement for the first, getDescriptorKeys. The second, getDescriptor, could be deprecated since it becomes just a convenience method on top of getDescriptorValue – but since it already exists, I'd suggest not deprecating it (even though I'm no fan of adding convenience methods). > As for the descriptor constants, some are carried forward from > JSR-170, while others are new. The new ones, according the proposal, > will have values in Java package form while the old ones stay the > same. Is that right? For repository-specific descriptors, the proposal recommendeds package-style naming. For standard descriptors, the intent was to follow the existing patterns for both the names and the values of the constants, since quite a few JSR-170 descriptors are being carried forward. > For those constants not carried forward (though still present in the > src) I assume that isStandardDescriptor should return false and > getDescriptorValue should return null. Correct? I'd suggest isStandardDescriptor return true, getDescriptor return a value with the same semantics as JSR-170, and getDescriptorValue return the same thing but as a Value instead of a String. Here are the JSR-170 descriptors not mentioned in the proposal, and how I suggest we treat each. REP_NAME_DESC REP_VENDOR_DESC REP_VENDOR_URL_DESC REP_VERSION_DESC SPEC_NAME_DESC SPEC_VERSION_DESC not compliance related; no change from JSR-170 OPTION_QUERY_SQL_SUPPORTED constant is deprecated; true iff the (deprecated) JSR-170 SQL query language supported QUERY_XPATH_DOC_ORDER QUERY_XPATH_POS_INDEX constant is deprecated; false unless the (deprecated) JSR-170 XPath query language supported; if supported, same semantics as JSR-170 LEVEL_1_SUPPORTED constant is deprecated; true iff OPTION_XML_EXPORT_SUPPORTED = true, and QUERY_LANGUAGES is non-zero length (this definition gives the descriptor the same semantics as in JSR-170) LEVEL_2_SUPPORTED constant is deprecated; true iff LEVEL_1_SUPPORTED = true, and WRITE_SUPPORTED = true, and OPTION_XML_IMPORT_SUPPORTED = true (this definition gives the descriptor the same semantics as in JSR-170)
          Hide
          Peeter Piegaze added a comment -

          Fixed. New COmplaince se3ction added and src updated

          Show
          Peeter Piegaze added a comment - Fixed. New COmplaince se3ction added and src updated

            People

            • Assignee:
              jsr-283-issues
              Reporter:
              anchela
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: