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


Well, yes and no.

The identity of a resource is indicated by an identifier that uniquely resolves to that resource but that identifier does not need to have any reference to a version.  Now one can say the identifier implies a version but the identifier does not have to reference a description of the versioning scheme used.  For example, using the date as part of an identifier can indicate a unique resource without specifying any version information.  For example, if my identifier strategy says that every Friday afternoon I will make available the latest configuration of a resource, I may have multiple Fridays where the identifies created even if there is no change in the configuration during the week.  In that case, last week's and this week's identified resource would be the same.

Now we get to versioning.  A version should be consistent with a scheme that defines a configuration of the resource.  This is where the idea of backward or forward compatibility comes in.  it is not enough to say this is version 1.1 and the last version was 1.05 unless I also define a consistent scheme from which these version numbers are derived.

Note, versions can be defined that don't use consistent or any numbers for versions.  As an example noted in the previously distributed discussion on versioning,  Microsoft's major release versioning of its operating system is Windows 95, Windows 2000, Windows XP, Windows Vista.  For Apple, the current versioning is 10.1, 10.2, 10.3, 10.4, 10.5 but this is not consistent with what version numbers meant prior to OS X.

So while versions are often associated with identity and time, this is neither necessary nor sufficient.

Ken

On Jun 25, 2008, at 6:19 PM, Francis McCabe wrote:

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

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

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.

Frank

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 of
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 identifiers
or date-time string etc.

Duane


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




Version

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.



Frank





--
**********************************************************************
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 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html
**********************************************************************


---------------------------------------------------------------------
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 OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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



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





smime.p7s



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