OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [soa-rm-ra] Version

I do not see a problem with version being a possible attribute of
identity.  So identifier and (optionally) version are both attributes of
identity.  Version and identifier are usually two different things in
> Version
> An identity associated with a resource that establishes a time and/or
> place where the resource is located.

As a counter example, I can install an interface on my computer and look
at the version to let me know what the capabilities of the interface
are.  In this case, version doesn't say anything about time or place. 
If it were a document, then version would give me some indication of
Based on the above, the following alternative definition follows:
An attribute of identity associated with a resource that establishes a
history of a resource.

-------- Original Message --------
Subject: Re: [soa-rm-ra] Version
From: Francis McCabe <frankmccabe@mac.com>
Date: Wed, June 25, 2008 3:19 pm
To: Ken Laskey <klaskey@mitre.org>
Cc: Duane Nickull <dnickull@adobe.com>, soa-rm-ra

Here is why I thought that version was connected to identity: 

A resource is a time varying entity that has value to someone (or

A version identifies a particular state of the resource at a particular
moment in time (could include space too).

The resource may or may not have any 'awareness' of its versions. In
fact, I would argue that most of the time it does not. 

Consider a description of a service. That description will have many
aspects to it. It may also identify which version of the service the
description pertains to.

Now, consider versioning the description itself. In the case of a
description, it is a structure artifact and so it may be possible to
'fit' any version identification of the description into the description
itself. But, if the description was designed to a specification that
neither enabled versioning nor enabled extensions, then you could not
embed version info into the description artifact (straw man I now, but
other resources have no space for version info).

On the other hand, a repository that held service descriptions is likely
to need to handle multiple versions of a description for a given
resource. The repository has to be able to distinguish multiple versions
of an artifact irrespective of whether that information is embedded
within the artifact.

In effect, the repository has to combine the name of the artifact with
the version info of the artifact in order to be able to unambiguously
identify the correct version of the artifact.

Hence the idea of the version being an aspect of identity rather than a
part of the resource itself. Identity is outside the identified entity.


On Jun 25, 2008, at 8:54 AM, Ken Laskey wrote:

As a refresher of thoughts on the issue, see the attached. 

<versioning draft.doc>

On Jun 25, 2008, at 11:50 AM, Duane Nickull wrote:

I think first of all, a version is not a specialized type of identity.

I would roll identity and identifier into one (identifier is the token
the identity)

Version is an attribute of "resource" IMO.  It usually is denoted with a
major_version.minor_version.release in software but I think it is too
granular so I would just stop at version and not include version
or date-time string etc.


On 25/06/08 8:21 AM, "Francis McCabe" <frankmccabe@mac.com> wrote:

This is a just a noodle. But, I was trying to see how versions fitted
with the resource model and came up with ...


An identity associated with a resource that establishes a time and/or
place where the resource is located.

Resources are generally time varying in nature – accessing a resource
at one time will often lead to a different outcome than accessing it
at another time. As a result, it may be necessary to identify a
resource at a point in time – in effect to identify a specific version
of a resource.


Senior Technical Evangelist - Adobe Systems, Inc.
Duane's World TV Show - http://www.duanesworldtv.org/
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
Adobe MAX 2008 -

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in

Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]