[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposed changes for ICOM version control model
|
Hello all, I propose to define the “Representative
Copy” as an optional feature of ICOM version control model for
compatibility with CMIS version control model. CMIS
defined the concept of “version-independent” membership in Folder
and Relationship. It is conceptually similar to ICOM “Representative Copy”,
however the “version-independent” behavior is specified without
requiring a “version-independent” objectid. I believe there is a
utility for a “version-independent” objectid to represent the
“Representative Copy” for bookmarking, tagging, and externalized
URL of a document without resorting to Navigation service requests.
I don’t see how a tag or an externalized URL for the
“Representative Copy” can be supported in ICOM (that is without resorting
to Navigation service) if we don’t define a special objectid which is independent
of any versioned copy or PWC. Below are excerpts of Section
2.1.11.8 and 2.1.11.9 in the CMIS draft: http://www.oasis-open.org/apps/org/workgroup/cmis/download.php/43639/cmis11-draft.pdf.
2.1.11.8 Version
Specific/Independent membership in Folders Repositories MAY treat membership
of a document object in a folder collection as "version-specific" or
"version-independent". Repositories MUST indicate
whether they support version-specific membership in a folder via the "capabilityVersionSpecificFiling"
optional capability flag. (See section 2.1.1.1 Optional Capabilities.) If the repository is treating
folder collection membership as "version-independent", then: _ Moving or filing a document
object into a folder MUST result in ALL documents in the version series being moved/filed into the
folder. _ The repository MAY return only
the latest-version OR latest major-version document object in a version series in the response
to Navigation service requests (getChildren,
getDescendants), and NEED NOT return other
document objects filed in the folder that are in the version series. If the repository is treating
folder collection membership as "version-specific", then moving or
filing a document object into a folder
MUST NOT result in other documents in the version series being moved/filed. 2.1.11.9 Version
Specific/Independent membership in Relationships A relationship object MAY have
either a version-specific or version-independent binding to its source and/or target objects.
This behavior MAY vary between repositories and between individual relationship types defined for a
repository. If a relationship object has a
version-independent binding to its source/target object, then: _ The getObjectRelationships service invoked on a document
object MUST return the relationship if relationship was
source/target is set to ANY Document Object in the version series. If a relationship object has a
version-specific binding to its source/target object, then: _ The getObjectRelationships service invoked on a document
object MUST return the relationship if relationship was
source/target is set to the id of the document object on which the service was invoked. Section 2.1.11.5.4 of CMIS draft
states that it is up to the repository whether it uses the objectid of the PWC
for the latest version when PWC is checked in: “If
the check-in returns a new cmis:objectId, then the PWC object MUST disappear if
the checkIn call was successful and the new checked in version will use the new
specified id.” Section 2.1.11.7 of CMIS draft
states that when a document is created in the repository it is treated as a PWC: “A
repository MAY create new document objects in a "Private Working
Copy" state when they are created via the createDocument or createDocumentFromSource
services.” To be compatibility with these specifications
in CMIS, I propose some changes in ICOM specification. ICOM currently defines the
following three types or states of a versionable artifact: A
versionable artifact is 1. a representative copy, 2. a specific versioned copy, or 3. a private working copy of
an artifact version series. I propose to add one more state
called non-version-controlled
copy (which is a special case of CMIS private
working copy) for compatibility with CMIS and define representative copy as
optional: A
versionable artifact is 1. a non-version-controlled copy, 2. (optional) a representative copy, 3. a specific versioned copy, or 4. a private working copy of
an artifact version series. ---------------------------------------------------- Current text: When
a versionable artifact is not under version control, a representative
copy of a versionable artifact is the only version
of a version series and represents the versionable artifact itself, i.e. there
is only one objectId so far. Proposed change: When
a versionable artifact is not under version control, a non-version-controlled
copy of a versionable artifact is the only copy
of a version series and represents the versionable artifact itself, i.e. there
is only one copy and one objectId so far. ----------------------------------------------------- Current text: When
a versionable artifact is under version control: ·
a
representative copy of a versionable artifact is a versionable artifact which
has its own object identifier that is different from the object identifier of any
versioned copy or private working copy of the versionable artifact. It retains
the object identifier it has when the artifact is created. Its version type
changes from RepresentativeCopy to
ViewOnlyRepresentativeCopy when version control is started. ·
a representative
copy of a versionable artifact provides a view of a version series, depending
on the check out state of the version series and the user loading the artifact.
If the current user loading a representative copy is the same user who checks
out from a version series, the representative copy is a copy of the content and
state of a private working copy. Otherwise, the representative copy MAY be a
copy of the content and state of the latest versioned copy in a version series. Proposed change: When
a versionable artifact is under version control, the service provider MAY optionally
provide a representative copy. If
a representative copy is provided, it is managed differently from a non-version-controlled
copy, any specific versioned copy, or a private working copy as
follows: ·
a
representative copy of a versionable artifact is a versionable artifact which
has its own object identifier that is different from the object identifier of any
versioned copy or private working copy of the versionable artifact. ·
assignment
of object id to a representative copy is implementation-dependent. ·
A representative
copy MAY retain the object identifier of a versionable artifact when it was a non-version-controlled
copy, i.e. when the artifact was created in the repository. In this case, the
version type of a versionable artifact SHALL change from NonVersioncontrolledCopy to RepresentativeCopy when
version control is started. ·
A representative
copy MAY be assigned a new object identifier that is different from a non-version-controlled
copy. In this case, the version type of a versionable artifact MAY change
from NonVersioncontrolledCopy to VersionedCopy
when version control is started. ·
a representative
copy of a versionable artifact provides a view of a version series, depending
on the check out state of the version series and the user loading the artifact.
Note: A
container of a versionable artifact can contain a representative copy of a
version series so that it MAY provide an artifact view of the latest
state of the version series. Starting from a representative copy in a
container, an actor can traverse a version series to retrieve any versioned
copy or private working copy.” ------------------------------------- Other texts that remain: A
specific versioned copy of a versionable artifact is an explicit
”deep” copy of the content and state of a versionable artifact,
preserving its content and state at a certain point in time. Each versioned
copy of a versionable artifact is itself a versionable artifact, i.e. it has
its own objectId. A versioned copy has a version number, label, and
check in comment. A
private working copy of a versionable artifact is a versionable artifact
created by an explicit checkout operation on a versionable artifact under version
control. The properties for a private working copy SHOULD be identical to the
properties of a versioned copy of a versionable artifact on which a checkout
operation was performed. Certain properties such as objectId and creationDate
SHALL be different from a versioned copy. The content of a private working copy
MAY be identical to the content of a versioned copy. Its object identifier must
be different from that of the representative copy or any versioned copy. A
private working copy can be saved to the version series for sharing and
co-editing, however, it needs not be visible to users who may only have
permissions to view other versioned copies in a version series. Until it is
checked in using an explicit checkin operation, a private working copy MUST NOT
be considered the LatestMajorVersion in a version series. Thanks, Eric |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]