Re:
item 2.
Namespaces don't imply versioning or ownership - they are used to help
define a universal name. Using a namespace will differentiate 2 interfaces from
each other that use the same name for an operation, for instance. A new revision
of an interface needs a new namespace in order to provide the new universal name
for the interface. It is important to allow a universal name for both the old
interface and the new interface because both will exist at the same time. It is
not important that the namespaces have a "birthdate" in them or even have a
version number - only that they are different.
For
instance, the following are not related to each other by a "birthdate" or
version number:
Bryan
Igor,
I
apologize, but again have conflicting meetings and will miss the the Thursday
call tomorrow.
I am
substantially in agreement with your diagram. I believe it is more
important that the versioning concepts are expressible in the MOWS model than
we agree on the details of the model. I do have
a few observations:
1.
It is not clear why Description need to be a separate entity rather than
simply an attribute of Interface and Service. I realize whether a
characteristic of an entity type is expressed as an attribute or an associated
entity is a choice that largely depends on a modelers's style. But in this
diagram, treating Description as an attribute would seem to simplify the
diagram. For example, we would not need the Description Version entity
type if we expressed Descrption as an attribute of the Interface and
Service entity types.
2. I
have serious concerns over the use of targetNamespace as the version
identifier. targetNamespaces are associated with XML
documents and it is not clear there will always be a 1-1 mapping between XML
documents (e.g the WSDL document instances) and the instances of the entity
types Interface and Service. Also, there are more philosophical
concerns about the use of namespace. For example, namespaces were intended to
express the notion of "ownership" (my namespace vs your namespace), not
versioning. I admit that they namespaces have been hijacked as a
convenient place to add version information - a common practice, but one that
may not be well advised. A better approach would be to treat ownership
and versioning as orthogonal concepts and use a separate element.attribute for
each.
Regards,
Brian
-----Original Message-----
From:
Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Tuesday,
November 04, 2003 10:31 AM
To: Brian Carroll;
wsdm@lists.oasis-open.org; Andreas Dharmawan
Subject: RE:
[wsdm][OMod] Updated Mows data model with versioning
Brian,
1. The versioning was to be expressed in a detail
diagram, *in addition* to the concepts diagram. Otherwise the concepts
diagram becomes cluttered with way too many things. Also today, per core
WSDL there is nothing like what was expressed. We have to keep a
practical, concrete point of reference.
2. The diagram had to express that a "versioned
element X is an element X", not the vice versa. In your diagram, for
example, it is expressed that a "functional interface" is an "interface
version" which is not excatly true, IMO.
So, I attemted to reformulate your diagram with the
above two concerns. The diagram is attached. The words to follow the diagram
are as follows.
"
The elements of the Web services acrhitecture,
expressed in WSDL, could be versioned. For example description, interface,
service and endpoint could be defined in their own namespaces (not
necessarily the same). The namespace could be used to contain the version.
Therefore, those elements, conceptually become veriosned. For example a
versioned service is a service that is also a versioned component that has a
version attribute.
Versioned components have revisions that are
related to each other via changes that happened between revisions. Each
change indicates a predcessor and sucessor (if any) revisions. Each change
may aggregate multiple change descriptions. Each change description may be
looked at as a document or a separate statement of some sorts (e.g. "new
interface was implemented").
"
-- Igor Sedukhin
.. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
Igor and all,
Here is an updated slide for the overall MOWS data model that
includes versioning. Sorry for the delay, but I just obtained Visio
2003 yesterday.
The Change entity relates two Service Versions. For clarity,
I've taken Zulah's comments to heart and renamed the relationships between
versions as "predecessor and successor".
Igor, I will send the updated Visio file to you in a separate
e-mail.
Regards,
Brian
Notice: This email transmission and/or the
attachments accompanying it may contain confidential information belonging
to Merant. The information is only for the use of the intended recipient. If
you have received this transmission in error, please notify the sender
immediately by reply email, and then destroy all copies of the transmission.