[dais-wg] WS-DAI latest update

Fri Jul 8 11:37:36 CDT 2005

Here is the latest WS-DAI doc. 

This is up on gridforge along with the WSDL. See the current docs folder. 
Be warned that I haven't made all of the required changes yet. Here is the 
list of what we covered in the telcon today. I have marked the ones I have 
done. 

=================================================

WS-DAI
------

-----------------------------
Page 3, Sec 1.2: the mapping is described as being to WSRF - this should 
be 
described as being to WSDL.

Done

-----------------------------
Page 4, Sec 3.1: 'manage the lifetime of the data within it' - this isn't
quite right, as the service can be used to control the lifetime of the 
data
in a resource, it's just the lifetime of the resource that can't be 
managed
by the service.

Done

-----------------------------
Page 5, Sec 3.2: 'Data Conduit'.  We need a better name, as we now 
introduce
a new concept when really all we mean is the use of WSRF to identify a 
resource.  How is 'WSRF Data Resource'?

Changed to WSRF Data Resource
Done.

-----------------------------
Page 5, Sec 3.3: 'Data Catalog'.  This tripped someone up from the 
audience,
as catalog meant something to them. I wonder about 'Resource List' 
instead.

Changed to Resource List
Done.

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

OK as is. 
Done.

-----------------------------
Page 5, Sec 4: We need to have a property that indicates whether or not a
resource is external or service managed.

DataResourceManagement property added
Done.

-----------------------------
Page 6, Fig 1: Surely a service-managed data resource must be associated 
with
either 1 or 1..* services.  I think I prefer '1'.

Done

-----------------------------
Page 9: We need to think through the semantics of data services derived 
from
other data services by checking through the properties describing derived 
data services to make sure they all make sense together.

TBD - to be addressed on later call.

-----------------------------
Page 10, Sec 5: 'MUST' be retrieved - what does this mean in this case - 
they
MUST be able to be retrieved?  Is it intended to mean that they can only 
be
retrieved tis way?

Changed to MAY.
Done.

-----------------------------
Page 11, Sec 5.1.2: should the type of this be a string?  Better to have 
<EPR,OptionalName> pair?

Agreed, have changed to DataResourceAddess but need rework of the name re. 
WS-Naming.
Done

-----------------------------
Page 12, Sec 5.1: do we have a property that indicates the languages 
supported
on a resource?

No
Done.

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

Possible. Lets discuss. It could of course go in DataResourceDescription
Add a CIMDataResourceDescription as a static property? need to speak to 
Sue if this is sensible
we believe this will provde helpful information about using the generic 
query message

-----------------------------
Page 15: 'RequestMessageResponseTypeList' - name has changed.

Done

-----------------------------
Page 18: Do we have a property that describes the schema of the 
configuration
document in the RequestMessage?

Yes - Fixed the text to point this out
Done.

-----------------------------
Page 18, DataResourceAddress: if we made the AbstractName manadatory, then 
the
actual message bodies would be identical in the WSRF and non-WSRF cases; 
this
might be good for consistency, if less good for making the WSRF 
representation
first-class.

Ok - have done this but need to check the text for consistency. 

-----------------------------
Page 18: end point(s) - why > 1?  What are the semantics of that?

This has now been changed to an address = single EPR. Is this correct?
Done.

-----------------------------
Page 19, Sec 5.5.2: Resolve.  Seemingly there is a Resolve message in the
WS-Naming document, which they hope to submit very shortly, so we could
consider using that rather than defining our own.  I have heard that this
proposal perhaps also supports the inclusion of an AbstractName within a
wsa, in a way similar to the way that WSRF has an opaque resource 
identifier
there.  I note that that might be seen as an alternative to names in 
message
bodies, although perhaps not on suitable timescales.

Correct but there is no spec yet.
Leave as DAIS messages for now.
Done.

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

Should I just remove them an say that use messages defined by WSRF?
Add See WS-ResourceProperties, WS-ResourceLifetime and remove messages
Add destroy back into 5.3

Done.

-----------------------------
Page 20, Sec 6.2.2: need to describe input/output messages in more detail.

N/A
Done.

-----------------------------
Page 20, Sec 7.1: standardised with -> standardised by.
Done

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

Non WSRF -> Fault
WSRF -> Remove just the WS-Resource not the data resource.

-----------------------------
Page 21, Sec 7.1.4: message for -> messages for
Done.

-----------------------------
Page 23, Acknowledgements: 'is active, and ... contributed' -> has 
benefitted 
from many people contributing ....
Done

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

What if a data resource is service managed by was not derived from 
another data
resource.  We don't provide operations for that, but one could see how a 
factory
could take the initial values for a resource as a parameter.

A factory message can result in either Service or Externally managed 
resource. Fix text. 

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

-----------------------------
MessageResponseMap is used in the data factory section where you mean 
MessageConfigurationMap.

-----------------------------
In WS-DAI the format of a data access request is:

</RequestMessage/>

<wsdai:DataResourceAbstractName/>?

</RequestDocument//>

<wsdai:ResponseType/>?

<//RequestMessage/>

In WS-DAIR the DataResourceAbstractName has become ResourceName, and 
ResponseType is named as ResponseFormat - seems better to match 
precisely where possible? 

-----------------------------

In the WS-DAI specification, it states that the

<RequestDocument/>

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

However, in the relational realisation, there are separate elements for 
the expression and its parameters.  I am wondering if this is an 
unnecessary departure from the template.

Need fix text in WS-DAIR - WSDL is OK. MA to do.

Simon Laws
IBM Hursley - Emerging Technology Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20050708/7bf552d6/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Grid_Data_Service_Specification-060705.doc
Type: application/octet-stream
Size: 592384 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dais-wg/attachments/20050708/7bf552d6/attachment.obj 