From jim_pruyne at hp.com Wed Jul 5 01:00:04 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 05 Jul 2006 01:00:04 -0500 Subject: [graap-wg] telecon on 7/5 Message-ID: <44AB5564.5000800@hp.com> We will have a telecon. on Wed. morning/evening. Dial-in numbers will be the same: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Daylight Time US 1500 UK 1600 Germany 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. From andreas.savva at jp.fujitsu.com Wed Jul 5 05:20:28 2006 From: andreas.savva at jp.fujitsu.com (Andreas Savva) Date: Wed, 05 Jul 2006 19:20:28 +0900 Subject: [graap-wg] url for the Web Services Policy WG in W3C In-Reply-To: References: Message-ID: <44AB926C.8080007@jp.fujitsu.com> Asit, Thank you for the detailed response. I am not objecting to aligning WS-Agreement to other standard WS specs. My objection is specific to the status of WS-Policy. Simply put, we think that standards should build on standards. Not on drafts, public or otherwise. WS-Policy has been submitted to the W3C (a good thing) but this is just the beginning of the standardization process for that spec. Can anyone claim that the final product of the WS-Policy WG will be exactly the same as this initial submission? For me this out weighs any benefit that might be obtained from making a point that should be obvious to people familiar with the specifications anyway. I would like to see the WS-Agreement specification, which already has a number of implementations, published. It's been in draft mode too long. Andreas Asit Dan wrote: > > Andreas, > We didn't have a discussion on this in our weekly call. As Karl > and Toshi noted that this is a trivial change (and Heiko provided a > validated schema with this change), so from a pure technical > implementation viewpoint this doesn't impact the spec even at this late > stage. > > I believe this is a very important issue, and we should have a well > reasoned and well articulated position on this for the wider audience -- > whatever may be the final decision of the group. The issue will keep > coming up as the wider audience (Web Services community) will fail to > grasp the strong objections of this group to aligning this spec to WS* > stack, and WS-Policy in particular. I believe the goal of this group is > to make WS-Agreement specification to be adopted by the wider Web > Services community, and not to be perceived as something niche for job > scheduling or just "Grid-thingy". Off course, in the same spirit, I > (we) have equally strongly advocated to the JSDL community for > leveraging this spec in specifying flexible scheduling objectives. > > There are several benefits from this change: better alignment and > acceptance by the broader WS* community and also avoiding confusion on > SLA vs Policy. A wide spectrum of folks I hear from in my everyday > activities (architects, developers, customers, analysts...) don't quite > distinguish SLA and Policy. [ Off course, that's not my position.] > Typical comments I hear -- are you using WS-Policy in specifying > service level assertions? By embracing the use of WS-Policy as an > envelope for agreement terms we not only avoid this confusion but also > easily demonstrate what additional aspects are being covered by WS-Ag > spec. Finally, in the runtime enforcement environments (service > registry, monitoring system, workload manager, ... ) SLA derived > enforcement policies can be represented uniformly. > > Given that WS-Policy draft (that has been submitted to W3C) is very > stable - has been co-authored by representatives from several > organizations, already implemented by many vendors and many other OASIS > standards on security, transaction, reliability, etc. dependent on this > spec - and changes to the current draft of WS-Ag spec is minimal (not > surprising, since we started with WS-Policy for term composition), there > are many good reasons to embrace WS-Policy now. In any case, it's a > public document (W3C), and we can make WS-Ag spec dependent only on > the submitted draft. > > Regards. > Asit Dan, Ph.D. > SWG SOA Design Requirements > Phone: (914) 766-1767 > Internet: asit at us.ibm.com > ICSOC 06 PC Chair (http://www.icsoc.org) > > > *Karl Czajkowski * > Sent by: owner-graap-wg at ggf.org > > 06/28/2006 03:20 AM > > > To > Andreas Savva > cc > "'GRAAP-WG'" , Toshiyuki Nakata > , Asit Dan/Watson/IBM at IBMUS > Subject > Re: [graap-wg] url for the Web Services Policy WG in W3C > > > > > > > > > I agree. It doesn't seem to add much to WS-Agreement at this point, > and I think people who want to engage in an "SLA and policy" > discussion should be able to observe the trivial mapping necessary > to understand our compositions as policy composition. > > karl > > > On Jun 28, Andreas Savva modulated: > ... >> I've read Toshi's previous email on pros/cons and I agree with him. I >> think at this point (one step before publication of the WS-Agreement >> spec) making a change that brings back a dependency on a specification >> that is about to enter the standardization process is not a good idea. >> >> -- >> Andreas Savva >> > > -- > Karl Czajkowski > karlcz at univa.com > > -- Andreas Savva Fujitsu Laboratories Ltd From karlcz at univa.com Wed Jul 5 05:45:22 2006 From: karlcz at univa.com (Karl Czajkowski) Date: Wed, 5 Jul 2006 17:45:22 +0700 Subject: [graap-wg] url for the Web Services Policy WG in W3C In-Reply-To: <44AB926C.8080007@jp.fujitsu.com> References: <44AB926C.8080007@jp.fujitsu.com> Message-ID: <20060705104522.GN22679@moraine.localdomain> On Jul 05, Andreas Savva modulated: > Asit, > > Thank you for the detailed response. > > I am not objecting to aligning WS-Agreement to other standard WS specs. > My objection is specific to the status of WS-Policy. Simply put, we > think that standards should build on standards. Not on drafts, public or > otherwise. WS-Policy has been submitted to the W3C (a good thing) but > this is just the beginning of the standardization process for that spec. > Can anyone claim that the final product of the WS-Policy WG will be > exactly the same as this initial submission? For me this out weighs any > benefit that might be obtained from making a point that should be > obvious to people familiar with the specifications anyway. > > I would like to see the WS-Agreement specification, which already has a > number of implementations, published. It's been in draft mode too long. > > Andreas > I agree with this sentiment. I also suggest that we not ignore the possibility of a minor "point release" to generate a new updated WS-Agreement spec with new namespaces and possibly this WS-Policy dependency when such a standard is finalized. I think we put too much emphasis on trying to find one perfect snapshot, rather than accepting different snapshots for different purposes. The existing implementors have an interest in standardizing their services. Some of us (like me ;-) expect further experience w/ the first WS-Agreement standard to likely inform changes for a future version, since this whole area is underexplored in practice. Clearly, nobody is advocating that we put out one WS-Agreement spec and then retire forever since it is perfect... karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Wed Jul 5 09:26:56 2006 From: t-nakata at cw.jp.nec.com (t-nakata at cw.jp.nec.com) Date: Wed, 5 Jul 2006 23:26:56 +0900 Subject: [graap-wg] url for the Web Services Policy WG in W3C In-Reply-To: <44AB926C.8080007@jp.fujitsu.com> References: <44AB926C.8080007@jp.fujitsu.com> Message-ID: Resending ther conflicts... BR Toshi Sec.4 P.15 xs:NCName ? wsag:AgreementContextType wsag:TermCompositorType 4.2.1 P.18 ? /wsag:ServiceDescriptionTerm/@wsag:Name 4.2.3.1 P.20 The MANDATORY name attribute (of type xs:NCName) represents the name given to a term. ? wsag:VariableSetType 4.2.5.1 P.22 xsd:anyType 4.2.6.1 P.24 xsd:any * 5 P.30 xs:NCName ? 5.1.1 P.32 9.4.2 Resource Property wsag:Name P.45 The wsag:Name resource property is of type xsd:NCName. It MAY be empty if no name has been defined in the offer submitted. ** ID being string> Sec.4 P.15 xsd:string Sec. 4.1 P.16 Se. 5 P.30 9.4.3 Resource Property wsag:Id P.45 The wsag:Id resource property is of type xsd:string. It MUST be a defined and represents the ID (unique between the parties to the agreement) of the present agreement version. ------- NEC ???????????? ?????? Toshiyuki Nakata Executive Chief Engineer Central Research Laboratories NEC Corporation +81-44-431-7653 From t-nakata at cw.jp.nec.com Wed Jul 5 09:38:36 2006 From: t-nakata at cw.jp.nec.com (t-nakata at cw.jp.nec.com) Date: Wed, 5 Jul 2006 23:38:36 +0900 Subject: [graap-wg] url for the Web Services Policy WG in W3C In-Reply-To: References: <44AB926C.8080007@jp.fujitsu.com> Message-ID: To people who could not attend the telecon.. Apologies for my poor English.. The info below had been for some discussion in the telecon and unfortunately I could not find the peoples' address so sent it to the whole mailing list. So apologies and Best Regards Toshi > Resending ther conflicts... > > BR > Toshi > > Sec.4 P.15 > > xs:NCName > ? > > wsag:AgreementContextType > > > wsag:TermCompositorType > > > > 4.2.1 P.18 > > wsag:Name=?xs:NCName? wsag:ServiceName=?xs:NCName?> > ? > > > /wsag:ServiceDescriptionTerm/@wsag:Name 4.2.3.1 P.20 > The MANDATORY name attribute (of type xs:NCName) represents the name given to a term. > > wsag:Name=?xs:NCName? wsag:ServiceName=?xs:NCName?> > ? > > > wsag:Name=?xs:NCName? wsag:ServiceName=?xs:NCName?> > wsag:VariableSetType > > > 4.2.5.1 P.22 > xsd:anyType > > > 4.2.6.1 P.24 > > xsd:any > * > > 5 P.30 > > xs:NCName > ? > > 5.1.1 P.32 > > 9.4.2 Resource Property wsag:Name P.45 > The wsag:Name resource property is of type xsd:NCName. It MAY be empty if no name has been defined in the offer submitted. > > ** ID being string> > Sec.4 P.15 > > xsd:string Sec. 4.1 P.16 > > Se. 5 P.30 > > 9.4.3 Resource Property wsag:Id P.45 > The wsag:Id resource property is of type xsd:string. It MUST be a defined and represents the ID > (unique between the parties to the agreement) of the present agreement version. > > ------- > NEC ???????????? > ?????? > Toshiyuki Nakata > Executive Chief Engineer > Central Research Laboratories > NEC Corporation > +81-44-431-7653 > ------- NEC ???????????? ?????? Toshiyuki Nakata Executive Chief Engineer Central Research Laboratories NEC Corporation +81-44-431-7653 From maclaren at cct.lsu.edu Wed Jul 5 17:26:00 2006 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Wed, 5 Jul 2006 17:26:00 -0500 Subject: [graap-wg] url for the Web Services Policy WG in W3C In-Reply-To: <20060705104522.GN22679@moraine.localdomain> References: <44AB926C.8080007@jp.fujitsu.com> <20060705104522.GN22679@moraine.localdomain> Message-ID: <70CE3658-92C0-40A7-881A-2EDFD8919206@cct.lsu.edu> I know that I'm not a particularly active member of this group any more - nor the most ardent advocate of WS-Agreement ;-) But I have to say that I agree wholeheartedly with Andreas and Karl. This spec really needs to get published, and out into the world as soon as possible. Experience with building real systems is going to be crucial for developing future iterations of the spec. (Anyway, how else will we get to the point where you all realize that I was right about phased commit?) Cheers, Jon. On Jul 5, 2006, at 5:45 AM, Karl Czajkowski wrote: > On Jul 05, Andreas Savva modulated: >> Asit, >> >> Thank you for the detailed response. >> >> I am not objecting to aligning WS-Agreement to other standard WS >> specs. >> My objection is specific to the status of WS-Policy. Simply put, we >> think that standards should build on standards. Not on drafts, >> public or >> otherwise. WS-Policy has been submitted to the W3C (a good thing) but >> this is just the beginning of the standardization process for that >> spec. >> Can anyone claim that the final product of the WS-Policy WG will be >> exactly the same as this initial submission? For me this out >> weighs any >> benefit that might be obtained from making a point that should be >> obvious to people familiar with the specifications anyway. >> >> I would like to see the WS-Agreement specification, which already >> has a >> number of implementations, published. It's been in draft mode too >> long. >> >> Andreas >> > > I agree with this sentiment. I also suggest that we not ignore the > possibility of a minor "point release" to generate a new updated > WS-Agreement spec with new namespaces and possibly this WS-Policy > dependency when such a standard is finalized. > > I think we put too much emphasis on trying to find one perfect > snapshot, rather than accepting different snapshots for different > purposes. The existing implementors have an interest in standardizing > their services. Some of us (like me ;-) expect further experience w/ > the first WS-Agreement standard to likely inform changes for a future > version, since this whole area is underexplored in practice. > > Clearly, nobody is advocating that we put out one WS-Agreement spec > and then retire forever since it is perfect... > > karl > > -- > Karl Czajkowski > karlcz at univa.com > From hludwig at us.ibm.com Tue Jul 11 14:41:28 2006 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Tue, 11 Jul 2006 15:41:28 -0400 Subject: [graap-wg] Strings, QNames and videotape - or: many ways to skin a cat Message-ID: All, as the last outstanding item before closing on the final V1 of WS-Agreement, we need to settle on the use of strings, QNames and NCNames for descriptive names and IDs that we use in the schema and spec. Right now, it is a merry mixture, following various trends in the past. We have a number of options to address the restrictions that should apply to unique identfiers and desriptive names: - Unique identifiers could be strings (no restriction), QNames (one can/must use namespaces to structure ids), or NCNames (no QName). There are pros and cons to all of them but the most likely candidates seem to be strings or QNames. I don't see implementation reasons for NCNames right now. - Descriptive names could be strings or we may force NCNames. I don't see the point of telling people how they would like to call their agreement etc. descriptively. If a users thinks a:b:c tells him or her what is meant who wants to object. So I strongly propose the first. Applying the above thoughts to the schema, we yield: - a schema where all ids are QNames and all descriptive names are strings: - a schema where all ids and names are strings: To decide what is an id and what is a descriptive name I strictly went by the name of the attribute, finishing with Id or not. This might not be correct. For example, ServiceName coul dreally be an ID. Then we should call it that way and make it whatever we decide. If we go with string ids, it doesn't matter. This point is to be concluded in tomorrow's phone call and then applied to the text of the spec in the following day or two. Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20060711/ef8afc24/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: agreement_types_StringIDs.xsd Type: application/octet-stream Size: 10975 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060711/ef8afc24/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: agreement_types_QNameIDs.xsd Type: application/octet-stream Size: 10973 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060711/ef8afc24/attachment-0001.obj From karlcz at univa.com Tue Jul 11 22:43:02 2006 From: karlcz at univa.com (Karl Czajkowski) Date: Wed, 12 Jul 2006 10:43:02 +0700 Subject: [graap-wg] Strings, QNames and videotape - or: many ways to skin a cat In-Reply-To: References: Message-ID: <20060712034302.GX32277@moraine.localdomain> One comment, Heiko: I remember now that Globus developers have warned me that handling of QName simple typed attributes and elements in the Apache Axis stack is somewhat challenging. They requested the use of anyURI type instead, which has about the same level of namespace safety as QNames I think. I cannot remember the exact issue, but believe it has to do with the way the QNames are parsed and the order in which the namespace prefixes handled. :-( I think we should restrict our use of QNames to the explicit attribute and element tags we define, and not for use in field values. Particularly for places where we use the "ids" to correlate between fragments of Agreement documents, I think URIs which we treat opaquely are the way to go. I think equality matching for URIs is also well-defined and simple to program. I agree that descriptive fields, not used for correlation in our base protocol or agreement semantics, should just be string types. karl -- Karl Czajkowski karlcz at univa.com From jim_pruyne at hp.com Wed Jul 12 02:58:55 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 12 Jul 2006 02:58:55 -0500 Subject: [graap-wg] telecon on 7/12 Message-ID: <44B4ABBF.30209@hp.com> We will have a telecon. on Wed. morning/evening. Dial-in numbers will be the same: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Daylight Time US 1500 UK 1600 Germany 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. Primary discussion topic is to finalize decisions on use of QNames, anyURIs, and Strings in appropriate places in the schema. --- Jim From Anne.Anderson at sun.com Wed Jul 12 09:04:18 2006 From: Anne.Anderson at sun.com (Anne Anderson) Date: Wed, 12 Jul 2006 10:04:18 -0400 Subject: [graap-wg] telecon on 7/12 In-Reply-To: <44B4ABBF.30209@hp.com> References: <44B4ABBF.30209@hp.com> Message-ID: <44B50162.1080101@Sun.COM> In developing XACML, we were advised that use of QNames made digital signatures on instances harder because the QNames might be resolved into different byte-strings by the signer and the verifier. In that case, the cryptographic hash will not match and thus the signature will not verify. I don't know enough about XML/naming to show how this would occur, but our XML experts told us to avoid QNames. Anne Jim Pruyne wrote On 07/12/06 03:58,: > We will have a telecon. on Wed. morning/evening. Dial-in numbers will be > the same: > 9:00AM Central Daylight Time US (UTC-5) > which should be: > 10:00AM Eastern Daylight Time US > 1500 UK > 1600 Germany > 2300 Japan > 2100 Thailand > > Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the > US. > Conference code #8578310. > > Primary discussion topic is to finalize decisions on use of QNames, > anyURIs, and Strings in appropriate places in the schema. > > --- Jim > -- Anne H. Anderson Email: Anne.Anderson at Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 From karlcz at univa.com Mon Jul 17 21:31:52 2006 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 18 Jul 2006 09:31:52 +0700 Subject: [graap-wg] Re: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary In-Reply-To: <2BCF8A1CC7A24341BCAA8193857F947E3DBB3A@scsmsx413.amr.corp.intel.com> References: <2BCF8A1CC7A24341BCAA8193857F947E3DBB3A@scsmsx413.amr.corp.intel.com> Message-ID: <20060718023152.GE13074@moraine.localdomain> On Jul 17, Subramaniam, Ravi modulated: ... > Would it be accurate to observe that where the disconnect here is that > the view taken in the thread is that the establishment is the key and > hence having that bi-party is desired but I have taken the > "binding/honoring view" where the referenced parties define the > agreement? > Unfortunately, I don't think that is the disconnect. Apologies for this long e-mail, but I want to recap some of the issues which have haunted WS-Agreement. There are three different relationships, as you mention. This same debate was had regarding WS-Agreement, and it wasn't merely an issue of feature minimization, but also a philosophical issue: 1. The communicating parties in the "establishment" of the agreement, obviously important in WS-Agreement. These are the "initiator" and "responder" roles in our protocol. One can actually design multi-party protocols here, but the debate is whether this is desirable---whether it models the underlying relationships and decision-making that is to be exposed. 2. The obligated parties of the agreement. We basically map these to the protocol roles in WS-Agreement, but we recognize that they can be delegated relationships... this is part of the internal logic of the service to either make decisions or "broker" decisions. As you said, the communicating parties "represent" the obligating parties during the establishment of the agreement. This obligating relationship is actually what people are referring to when they say that, in practice, real world agreements that "appear" multi-party are really sets of bilateral agreements. This boils down to how the obligated parties can reconcile things with an auditer or within a legal system. This is complicated by the fact that new entities are sometimes introduced, e.g. a set of members agreeing bilaterally with an "association" over which the entities will also gain fractional control. 3. The services which are the subject of obligations. It sounds like everyone here is seeing this the same way, so I won't belabor the point. The two philosophical debates to be had are regarding the cardinality of these obligating relationships (2) and also whether the obligating relationships are important to informing the communication patterns and semantics of the protocol. I think the best reason to investigate real-world agreements/contracts is to see what we can learn from them about practical solutions that have been found. For example, this can inform us on the important differences between negotiation+agreement, performance, and reconciliation which may occur in different overlapping but not equal time periods. (For example, one might legally resolve a contract dispute after the "service period" is over, but before the contract has become legally irrelevant.) This has helped GRAAP-WG to delineate the function of WS-Agreement service representations: our service represents a basic negotiation and agreed-service monitoring infrastructure, but retires agreements to some presumed external entity for audit and reconciliation. Our agreement language is (hopefully) complete enough to guide the reconciliation phase, as well as to guide the actual negotiation and performance phases. However, I personally belong to the school which sees this as just a useful model for automated agreement patterns. It makes the distributed architecture more understandable to follow the social idioms used for human-based agreements and contracts. There are those who even question the legality of things like digital signature and non-repudiation. I do not want adaptive computing systems to really be forming legally binding obligations. With their problems, digital signatures are still much easier to justify than the idea that we can delegate legal responsibilities to a machine-driven decision process! I think there are examples of machine-driven, binding decisions out there, e.g. in the financial trading sector. But, I think many computer systems operators/owners will be scared away from Grid technologies if they are told that their computer will now begin signing contracts which bind the owner... I think we need a lower barrier to entry into this field. karl -- Karl Czajkowski karlcz at univa.com From jim_pruyne at hp.com Wed Jul 19 01:31:21 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 19 Jul 2006 01:31:21 -0500 Subject: [graap-wg] proposed final draft of WS-Agreement Message-ID: <44BDD1B9.7030306@hp.com> All, Attached is the proposed, final draft for WS-Agreement. I believe this has all outstanding items from public comment, and group discussion completed (thanks Heiko!). Rather than have a telecon tomorrow (7/19), I propose that we review this draft over the next week, and determine if we are satisfied with the state, and discuss on a telecon next week. The last bit of changes was determining how we wish to deal with IDs, and it was decided, ultimately, to simply stick with strings as feedback we heard said that other types are less certain in tooling, and the semantics of comparison were not clear. Given that the sole purpose of ids is comparison in a sense, we've decided (Heiko and myself on the call last week), that we would just stick with strings since both the tooling, and the meaning of comparison are well defined here. --- Jim -------------- next part -------------- A non-text attachment was scrubbed... Name: WS-AgreementSpecificationDraft20060718.doc Type: application/msword Size: 892928 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060719/1ca9ece8/attachment.doc From jim_pruyne at hp.com Wed Jul 19 01:32:13 2006 From: jim_pruyne at hp.com (Jim Pruyne) Date: Wed, 19 Jul 2006 01:32:13 -0500 Subject: [graap-wg] no telecon on 7/19 Message-ID: <44BDD1ED.1020709@hp.com> Folks, See my previous message with the draft of the specification. To give time to review, I'm canceling this week's call, and we'll meet again next week to finalize this draft. Thanks. --- Jim From t-nakata at cw.jp.nec.com Wed Jul 19 03:29:14 2006 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Wed, 19 Jul 2006 17:29:14 +0900 Subject: [graap-wg] no telecon on 7/19 In-Reply-To: <44BDD1ED.1020709@hp.com> Message-ID: <009001c6ab0d$6ae820c0$ab84380a@ISIBASI> Thanks to Jim and Heiko for all the updates. I've noticed that some of the changes I sent wrt the Status of WS-RF etc is not reflected so I will probably send the updated draft to the whole Group Best Regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: owner-graap-wg at ggf.org [mailto:owner-graap-wg at ggf.org] > On Behalf Of Jim Pruyne > Sent: Wednesday, July 19, 2006 3:32 PM > To: GRAAP-WG > Subject: [graap-wg] no telecon on 7/19 > > Folks, > > See my previous message with the draft of the specification. > To give time to review, I'm canceling this week's call, and > we'll meet again next week to finalize this draft. > > Thanks. > > --- Jim > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060719/bb666a60/attachment.bin From Wolfgang.Ziegler at scai.fraunhofer.de Wed Jul 26 08:49:07 2006 From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler) Date: Wed, 26 Jul 2006 15:49:07 +0200 Subject: [graap-wg] [Fwd: WSAG Draft] Message-ID: <44C772D3.2040906@scai.fraunhofer.de> Dear all, Here are some comments from my colleague Oliver: AgreementSchemaTypes: wsa-Namespace is not used (should be removed) wsrf-bf: fault section could be moved to wsdl, therefore eliminating the dependency to wsrf-bf in the xml-schema (only in wsdl). AgreementAcceptanceSchemaTypes: Namespaces wsa and wsrf-bf should be removed since they were not used in the schema. Best regards Wolfgang -- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 CoreGRID Network of Excellence www.coregrid.net Collaboration Gateway www.coregrid.net/cg Institute on Resource Management and Scheduling www.coregrid.net/irms -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2093 bytes Desc: S/MIME Cryptographic Signature Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060726/c0faf37d/attachment.bin From Wolfgang.Ziegler at scai.fraunhofer.de Mon Jul 31 02:40:07 2006 From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler) Date: Mon, 31 Jul 2006 09:40:07 +0200 Subject: [graap-wg] WS-Agreement workshop in conjunction with GGF18 Message-ID: <44CDB3D7.1050606@scai.fraunhofer.de> Dear all, as discussed at last GGF in Tokyo we will have a workshop addressing implementation and interoperability issues. Please see the call for participation below. Best regards Wolfgang ============================================================= First WS-Agreement Workshop September 10, 2006 Washington DC, USA in conjunction with Global Grid Forum 18 Deadline for 2-page contribution: *** August 20 **** Call for Participation ---------------------- The first workshop on WS-Agreement aims to identify: - Current WS-Agreement implementations - WS-Agreement interoperability concerns - Common terms used in WS-Agreement templates - Application specific terms used in WS-Agreement - Use cases for WS-Agreement *** All authors are requested to relate their work to the current version of WS-Agreement, which can be found at: https://forge.gridforum.org/sf/docman/do/listDocuments/projects.graap-wg/docman.root.current_drafts *** Submission Process ------------------ Developers/authors are requested to provide a 2-page document (in PDF format) single column, 10pt font size. The document should describe details of the WS-Agreement implementation and how it relates to the specification available at the above Web site. The 2-page document should be sent to Wolfgang Ziegler (wolfgang.ziegler at scai.fraunhofer.de), Omer F. Rana (o.f.rana at cs.cardiff.ac.uk), or Philipp Wieder (ph.wieder at fz-juelich.de) by August 20, 2006. The contributions will be evaluated and authors will be informed on August 28, 2006, whether their contribution has been accepted. Workshop details ---------------- Authors of accepted contributions are requested to present their work at the workshop. Demonstrations of work are particularly welcome. The workshop will be held in conjunction with the Global Grid Forum 18, on September 10, 2006, at the Washington Convention Center 801 Mount Vernon Place NW Washington, DC 20001 For more information regarding the venue, registration, and lodging, please visit http://www.ggf.org/GGF18/ggf_events_ggf18.htm. ============================================================= -- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 CoreGRID Network of Excellence www.coregrid.net Collaboration Gateway www.coregrid.net/cg Institute on Resource Management and Scheduling www.coregrid.net/irms -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2093 bytes Desc: S/MIME Cryptographic Signature Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060731/705b70a9/attachment.bin