Issue Details (XML | Word | Printable)

Key: JSR_283-435
Type: Task Task
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: jsr-283-issues
Reporter: anchela
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
jsr-283

Decision F2F Basel 07: new compliance levels

Created: 13/Mar/08 07:23 AM   Updated: 06/Jan/11 12:09 PM   Resolved: 17/Jul/08 03:12 PM
Component/s: general
Affects Version/s: current
Fix Version/s: milestone 1

Time Tracking:
Not Specified

Environment:

Operating System: All
Platform: All

Issue Links:
Dependency
 

Issuezilla Id: 435
Tags:
Participants: anchela, dpitfiel, jsr-283-issues and Peeter Piegaze


 Description  « Hide

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.



anchela added a comment - 31/Mar/08 06:57 AM

(improve subject)


Peeter Piegaze added a comment - 01/Apr/08 05:40 AM
      • Issue 345 has been marked as a duplicate of this issue. ***

Peeter Piegaze added a comment - 15/Jul/08 03:36 PM

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


dpitfiel added a comment - 15/Jul/08 04:22 PM

> 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)


Peeter Piegaze added a comment - 17/Jul/08 03:12 PM

Fixed. New COmplaince se3ction added and src updated