W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

Re: Random thoughts on the Abstract Model Task Force (AMTF)

From: Jacek Kopecky <jacek@systinet.com>
Date: Sun, 19 May 2002 13:35:05 +0200 (CEST)
To: Krishna Sankar <ksankar@cisco.com>
cc: www-ws-desc@w3.org
Message-ID: <Pine.LNX.4.44.0205171612080.19885-100000@mail.idoox.com>
 Krishna, please see my comments inside.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

On Sat, 11 May 2002, Krishna Sankar wrote:

 > Hi all,
 > 	Since our meeting last week, I have been thinking about the
 > Abstract Model Task Force and what does it mean for the progression (&
 > evolution) of the WSDL specs. Here is the summary of the sum of all my
 > thoughts on this subject:
 > 1.	Abstract Model
 > 	IMHO, we need an abstract model to capture the heart and soul of
 > WS D3 - Definition, Description and Discovery. The abstract model can be
 > in the primer as a non-normative section (of course the whole primer is
 > non-normative anyway) or may be in the core specs as an appendix.
 > 	I think the AM would be more useful in the 2.0 realm as a
 > reference model and guiding principle. Naturally it would evolve as we
 > progress into the architectural aspects of WS D3.

I think usefulness of the AM is orthogonal to the 1.2 vs. 2.0
issue. I view 1.2 as a small step and 2.0 as a big step with
significant changes. I do believe that the AM would be more
useful if we decided to do a rewrite as opposed to patchwork but
even in case we're noodling on the direction a particular patch
should go we can call the AM for help. See below for more on this

 > 	As Sanjeeva pointed out, the AM should not be another 30 page
 > description of the description language of the Web Services ! That would
 > defeat the purpose of an AM. UML is a good choice to express the AM.
 > This does not mean one requires a deep experience in UML to create and
 > understand the AM. We wouldn't be using all the nuances and primitives
 > of UML, as we ourselves are a description language. The AM will be
 > simpler in terms of UML - in fact most possibly we would use a
 > combination of UML and text.

I believe that if none of the AMTF speaks UML, it would be
inpractical to attempt to do the AM in UML. Of course if some of
us do speak UML enough to do this, they will be welcome. 8-)

 > 	Now coming to the timing (well, at least it rhymes well !),
 > IMHO, it is not a good practice to declare a do-or-die-by-the-June-f2f
 > for the AM. The major reason being, many folks do not have the bandwidth
 > now, but might be able to contribute in the next month or so. Also the
 > next two weeks are very difficult in terms of productivity - vacations,
 > long weekend, XML 2002,...

I agree here. 8-)
 > 2.	1.2-by-issues-patchwork-to-1.1
 > 	I think we still need to do the issues patchwork irrespective of
 > the AM and thus is not a substitute for AM or vice versa. I am of the
 > opinion that we have identified *most* of the issues for a 1.1 - 1.2
 > *transition*. May be we should have two buckets - fix now (1.2) and fix
 > later (2.0). Let us discuss issues quickly and put them into the
 > respective buckets. We will dig deeper into the 1.2 issues and will be
 > silent on the 2.0 issues till after the 1.2 is done. If, we as a team,
 > have that discipline, I think we can achieve our goals. Remember, the
 > earlier we get to 1.2, the faster we could start working on 2.0 !

Krishna, I'm afraid I don't know what you mean by "an issue for a 
1.1 - 1.2 transition". IMO we identify issues in 1.1 that need to 
be fixed and after we fix all of them we have our next version.

We can go two ways about the fixing - we can attempt to identify 
all issues and fix them with patches or we can write the doc from 
scratch, at best according to the AM, and then see if it 
addresses all the issues.

I don't believe we can have two buckets for fixes - if something
needs to be fixed it must be fixed. I do believe we can have two
buckets for features, though. There are design issues with the
features themselves and then issues with the spec text for these
features. The former must be all resolved, if only by saying "we
don't want this feature in 1.2" or "we want this feature in 1.2
in its present state". The latter must be resolved because we 
want a clear and consistent spec text.

Identifying the features is what the AM can help with.

Best regards,

Received on Sunday, 19 May 2002 07:35:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:23 UTC