[dais-wg] WS-DAI Issues

Fri Jul 8 09:48:53 CDT 2005

I have been keeping a list of the points people having been sending in. 
Here is where I am up to. I suggest we use time on the call today to go 
through the list. 

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

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

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

Not sure. Was trying to take account of the use of WSRF EPRs

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

Done - DataResourceManagement property added

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

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

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

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

No

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

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

-----------------------------
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 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 a address = single EPR. Is this correct?

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

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

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

-----------------------------
Page 20, Sec 7.2: standardised with -> standardised by.

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

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

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

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

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

-----------------------------
The second element in DataResourceAddress is described as:

/wsdai:DataResourceAddress /wsa:EndPointReference

rather than just

/wsdai:DataResourceAddress

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

WS-DAI Changes - Points to Note
===============================

I have changed DataResourceAddress to be an EPR where the pattern is to 
include the abstract name in the reference  parameters 

element of the EPR. In a similar way to WS-Naming except that WS-Naming 
uses <policy> that doesn't seem to exist now. 

<wsa:EndpointReference>
    <wsa:Address>xs:anyURI</wsa:Address>
    <wsa:ReferenceParameters>
      <wsdai:DataResourceAbstractName/>
    </wsa:ReferenceParameters>
    <wsa:Metadata> ... </wsa:Metadata>?
    <xs:any/>*
</wsa:EndpointReference>

Have changed all factory messages to return DataResourceAddressType. 
Should possibly be a reference to wsa:EndpointReference

Simon Laws
IBM Hursley - Emerging Technology Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20050708/98628c71/attachment.html 