DAIS Telcon 08 July 2005 ======================== Chair: Norman Paton Notes: Mario Antonioletti Attendees: Simon Laws, IBM Norman Paton, University of Manchester Mario Antonioletti, EPCC Dave Pearson, Oracle +--- Simon: Go through the email that Simon posted to the list regarding issues. http://www-unix.gridforum.org/mail_archive/dais-wg/2005/07/msg00007.html Page 5, Sec 3.8: As a resource may be identified by an endpoint and a separate abstract name, I wondered if this wasn't quite right. Simon: When I wrote this I was implying that the data resource includes an EPR and enough information to distinguish the data resource. Later on this is described in more detail in the factory section. Have a construct that has an EPR and the name of a resource. The WS-Naming draft states that the abstract name is included in the EPR and will be using that structure to use these pieces of information. Seems like a good idea. Wish to use this. Norman: the resource is identified by its address and in another case it is identified by the address and the abstract name. Hence the text in 3.8 is ok but it is not very precise. Maybe it should be more precise. Simon: could tidy this up but this is a general point as to what we think an address is .... Norman: so maybe that is alright ... is there a tighter definition later on? Simon: have reworded the naming section ... for the purposes of WS-DAI an abstract name is a URI, have included a bit of xml and changed the WSDL ... have also simplified the text that follows... Norman: so that structure is being used to feedback the result .... Simon: same as before but we got rid of a layer of XML which simplifies ... when passing a message to a DAIS resource the consumer must provide the address and information to discriminate the resource that is being used .... goes on to describe that the two cases fall out: WSRF and the non-WSRF section. Leave as is and tighten up later ... ... Page 12, Sec 5.1: do we have a property that indicates the languages supported on a resource? Mario: there is in the relational and now that if we have a generic query operation maybe this could be promoted to the core spec. Simon: but: Page 12: I wonder if we should have a placeholder here for a CIM description of the installed data resource management system. This is in practice the only way of working out what language expressions can be passed. Could use this to describe the language. Norman: may not be good to use a generic place holder ... have a top level query operation - we know the value it takes in as a parameter but we do not know what the actual language means ... there is no inter-operable way of defining this ... there is no formal way of describing this .... Mario: can't we just promote the language properties thing? Simon: concerned that you don't know what message it refers to ... languages supported at the top level does it only refer to the top level operation? Norman: yes.. Simon: then it does get a bit complicated ... Norman: with SQL you can be told what version of the standard it is claiming to support ... but you have a greater degree in the real world ... so you can get round that by specifying other things ... Simon: the data resource description has been introduced as a configurable property that you can introduce by the manager to describe it ... you could introduce another static property that describes the data resource ... do we say it's a CIM thing? ... Norman: at some point will people pick our spec and find the non-interoperable bits ... if we want to build an inter-operable thing we need to build in a model. Can connect into CIM to describe the DBMS and another to describe the Schema ... Dave: can say that we expect this that you will be able to do this once the CIM model is there.... Simon: so we add something like CIMDataResourceDescription as a static property to describe this sort of thing ... Norman: should check with Sue ... leave some CIM stuff in the relational one to describe the schema and a bit of CIM in here to describe the DBMS ... this will provide information on how to use the generic query operation ... ... Simon: Page 18: end point(s) - why > 1? What are the semantics of that? refers to something coming out of a factory. Have changed so this comes out of an EPR. If we want more than 1 then we would have to adjust the return type of the addresses. It is not a > 1 cardinality now. In the WS-Naming they are using an old version of WS-Addressing ... ... Simon: there is a very early draft of WS-Naming ... Dave: they say early draft in early June and specification on March '06 so can't really use as yet ... ... Simon: Page 20, Sec 6.2: As the conduit is a WS-Resource, surely it doesn't need these messages - instead they must be defined in such a way that they are available for all resources not represented as WS-Resources. Put some message to describe things generically but as we are now calling it a WS-Resource can we just say that these messages will be generically available. So can remove these messages and refer to WSRF. Norman: still need a destroy operation. Simon: need to put the destroy back in section 5.3 and put it back on the WSDL. ... Page 21, Sec 7.1.2: is it stated what the behaviour of lifetime messages is if the conduit is used with externally managed resources? Do the messages all fault? Norman: you could have an externally managed resource that is a WSRF data resource in which case you invoke a destroy ... ok in both case ... so the messages fault .... Simon: or the data resource goes away ... Norman: need to be clear ..... Simon: in the non-WSRF case it faults, but in the WSRF version. Dave: destroy is like a drop table command ... thinking whether it is necessarily a fault ... a user may want to remove it if they have created .... Simon: the case though it is an externally managed resource .. Dave: but if it is a derived data resource it could create this... Simon: we do not provide a way of specifying this ... Norman: but we have the property .... Simon: but I made that static ... Norman: so the factory can choose whatever it wants so it could be an externally managed resource... Simon: so do we fault or just remove the WS-Resource? Norman: my inclination is that you remove the WS-Resource else you are stuck with it for ever .... Dave: it's the kind of thing that they pick up on implementation.... Norman: they may complain if you can't remove a WS-Resource... Simon: but the data resource does not disappear. ... ParentDataResource: "If this data resource is a service managed data resource this property holds the data resource abstract name of the data resource from which it was generated. If the data resource is an externally managed data resource this property will be empty." Simon: wrote this text with a mistake understanding - a factory message can result in internally/externally managed resource so just need to fix the text ... Norman: could envisage created a service managed data resource out of band. ... MessageResourceMap: This is referred to in several places in the direct data access part of the spec where I think the reference should be to the MessageDatasetMap. Simon: have 2 maps where they were used inconsistently that needs fixing. ... "contains the request expression. The structure of this document is specific to the expression being used. The name of this element SHOULD indicate the language used by the expression." Simon: is there a requirement to change the WS-DAI? Norman: change the WS-DAIR version .... the request has been split over two top level elements ... Envisage that the parameters are not the top level .... ... Simon: moment have SQLExecuteRequest ... the WSDL is different from the spec? ... has executerequest .... Need to fix the relational text. ... Collecting the major points of change at the end of the message. Status is as in the message. WSDL and document match. Can put a new version on Grid Forge if that is useful ..... ...