[DAIS-WG] DAIS call Tomorrow DAI-RDF public comments required.

[Mike Jackson]

Hi all,

Some comments on the WS-DAI core/relational comments are attached.
cheers,
mike

On Mon, 1 Aug 2011, Isao KOJIMA wrote:

> 1) We now have the final review on WS-DAI core/relational spec from
> Dr. Alasdair Gray of Manchester
> university. Based on this review draft, we think we need to have a
> telcon tomorrow to discuss how we
> should go forward.
>
> This call will be held with WebEX as in the following info and please
> join if interested.
>
> 2) Our WS-DAI RDF(S) Spec is in public comment phase and we are still
> waiting for YOUR comments.
> The deadline is 6th August which is quickly approaching.
>
> Regards
> Isao Kojima and Oscar Corcho
> DAIS Co-Chairs
> OGF
>
> Topic: DAIS call
> Date: Tuesday, August 2, 2011
> Time: 5:00 pm, Japan Time (Tokyo, GMT+09:00)  9am in UK.
> Meeting Number: 869 584 606
> Meeting Password: dais
>
>
> -------------------------------------------------------
> To join the online meeting (Now from mobile devices!)
> -------------------------------------------------------
> 1. Go to https://itri-aist.webex.com/itri-aist-en/j.php?ED=182390742&UID=1208284902&PW=NZmZhNjg0MjM4&RT=MiM0OQ%3D%3D
> 2. If requested, enter your name and email address.
> 3. If a password is required, enter the meeting password: dais
> 4. Click "Join".
>
> To view in other time zones or languages, please click the link:
> https://itri-aist.webex.com/itri-aist-en/j.php?ED=182390742&UID=1208284902&PW=NZmZhNjg0MjM4&ORT=MiM0OQ%3D%3D
>
>
> -------------------------------------------------------
> For assistance
> -------------------------------------------------------
> 1. Go to https://itri-aist.webex.com/itri-aist-en/mc
> 2. On the left navigation bar, click "Support".
>
> You can contact me at:
> kojima at ni.aist.go.jp
>
> To add this meeting to your calendar program (for example Microsoft
> Outlook), click this link:
> https://itri-aist.webex.com/itri-aist-en/j.php?ED=182390742&UID=1208284902&ICS=MI&LD=1&RD=2&ST=1&SHA2=3glS9FJqSFzejY/m269RIEnYEYbqfqmmRsl7DVLzI/g=&RT=MiM0OQ%3D%3D
>
> The playback of UCF (Universal Communications Format) rich media files
> requires appropriate players. To view this type of rich media files in
> the meeting, please check whether you have the players installed on
> your computer by going to
> https://itri-aist.webex.com/itri-aist-en/systemdiagnosis.php.
>
> Sign up for a free trial of WebEx
> http://www.webex.com/go/mcemfreetrial
>
> http://www.webex.com
>
>
> IMPORTANT NOTICE: This WebEx service includes a feature that allows
> audio and any documents and other materials exchanged or viewed during
> the session to be recorded. By joining this session, you automatically
> consent to such recordings. If you do not consent to the recording,
> discuss your concerns with the meeting host prior to the start of the
> recording or do not join the session. Please note that any such
> recordings may be subject to discovery in the event of litigation.
>
> -----------------------------------------------------
> Isao Kojima
> Leader, Service-ware Research Group
> Information Technology Research Institute
> AIST,Japan
>
>

-------------------------------------------------------------------
Dr. Michael (Mike) Jackson        E-mail: m.jackson at epcc.ed.ac.uk
EPCC                              http://www.epcc.ed.ac.uk
Software Sustainability Institute http://www.software.ac.uk
OGSA-DAI Open Source Project      http://tinyurl.com/ogsa-dai
OGSA-DAI                          http://www.ogsadai.org.uk

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
-------------- next part --------------
WS-DAI
------

However, it fails to discuss RDF data, which given its increasing
importance for sharing data seems like a shortcoming.  

Major Issues 

At the start of Section 5.1 it is stated, "These properties MUST all
appear in the data access service that implements the data
description." Then in the definition of the properties some are
allowed to appear zero or more times, and are often left blank in the
example documents.
[
Just omit the MUST from the start of the section and add MUSTs for
5.1.1, 3, 4 or in intro say "MUST all appear...except where otherwise 
indicated"?
Would also need similar rephrasings in the related specifications.
]
The term "Readable" is really "SupportsQueries" the way it is
defined, although this is not the way that it is used in WS-DAIR.
[
Unclear as to what this means. If one can't read it one can't
query it.
Just change it to "clients can read the data resource via a WS
operation"? 
]
In Sections 5.2.6 and 5.2.7 the definition of "Sensitive" states,
"changes to the parent resource may be reflected"?. However in the
explanatory text in Section 5.2.6 the sentiment is that it "will" be
reflected. Do you need three levels of sensitivity: Insensitive,
MaybeSensitive, and Sensitive?  
[
Change the appropriate text into "will". Having a MaybeSensitive would 
be of little use to clients. A WS-DAI deployer will know whether a
resource be sensitive or not (affected by the nature of their
resources and also how WS-DAI and derived specifications have been
implemented.
]
Sections 5.3.1 and 5.4.1 are very different in content and style from
the surrounding sections. What is the relationship between 5.3.1 and
5.3.4? 
[
Combine 5.3.1 and 5.3.4 since 5.3.1 doesn't apply to 5.3.2 and 5.3.3?
]
In the code snippets in Section 5.3.1, why is one format URI passed as
an attribute and the other as an element? 
[
One is the request document LanguageURI. The other is the
DataSetFormatURI. 
These could be made consistent - either elements or attributes. Would
affect all related specifications though.
]
Sections 5.3.1 and 5.4.1 both define an element <RequestMessage> with
different parameters. Suggest that the name of the latter should be
changed to FactoryRequestMessage. 
[
They don't define elements. It's just an example. Could state this
and adopt his suggestion.
]
What are the faults associated with a factory method?
[
Can use same faults as GenericQuery with additional faults more
applicable to factories e.g. from WS-DAIR's factory ops we have: 

InvalidResourceNameFault - the supplied resource name is not known to the service.
DataResourceUnavailableFault - the specified data resource is unavailable.
InvalidPortTypeQName - the PortTypeQName specified is not in the collection defined by the ConfigurationMap property.
InvalidConfigurationDocumentFault - the ConfigurationDocument specified is not valid according to the ConfigurationDocumentQName when the ConfigurationMap is indexed by the specified PortTypeQName.
InvalidExpressionFault - the supplied expression is not of a form known to the service.
InvalidLanguageFault - the supplied expression language is not known to the service.
NotAuthorizedFault - the service-level authorization was unsuccessful, indicating that the consumer is not authorized to perform this operation at this time.
ServiceBusyFault - the service is already processing a request and ConcurrentAccess is false.
...plus additional DAIR-specific ones.
]
Section 5.4.1 defines some of the same elements as 5.3.1,
e.g. RequestDocument. Consider defining once in the document and
reusing to ensure there are no consistency issues. The same approach
should be applied to the DataResourceAddress list that is returned by
a factory method and the GetResourceList operation. 
[
Again need to emphasise that those elements are not definitions.
]
Section 9 should be rewritten given that OGSA is now a standard. 
[OK]

Minor Issues

The document number is stated as GFD-R.074. In the section "Status
of This Memo" it states, "This document obsoletes GFD-R.074". I
suggest that you correct this to avoid any confusion. 
[OK]
Abstract: "regular web services environments" -> "regular web
service environments" 
[OK]
To allow the document to be more self-contained, definitions for the
following should be provided in Section 2 or 3: 
-QName
-EPR 
[OK]
Figure 1, and the text immediately above it should be moved to the
beginning of Section 4.1. It is strangely placed in the Service
Managed Data Resource section. 
[OK]
p8: "are know to" -> "are known to"
[OK]
p8: (WSDL2.0 is now a recommendation) "The word interface is not
intended to refer specifically to the proposed use of the word
interface found in the candidate recommendation of the WSDL 2.0
specifications although this may be an appropriate mapping in the
future." -> "The word interface is not intended to refer
specifically to the use of the word interface found in the
recommendation of the WSDL 2.0 specifications [add citation] although
this may be an appropriate mapping in the future." 
[OK]
p8: Provide a definition for portType. Is portType an interface?
[
Shouldn't the reader know WSDL already? Can we put into the
introduction that we expect they should be familiar with it?
]
p9: "But, in order" -> "However, in order"
[OK]
p10: "messages allows a" -> "messages allow a"
[OK]
p10: "data resources configuration" -> "data resource"s
configuration" 
[OK]
Section 4.8: provide a citation to the resulting
document 
[OK]
p11: "relational data management" -> "relational database
management" 
[OK]
Section 5.1.8 appears at a strange point being in the
middle of the properties that it contains. Either move it before all
properties or after all properties. I would suggest making it its own
subsection (5.3) as is done in the WS-DAIR document. 
[OK]
p20: "http://www.ggf.org/dataforma1" ->
"http://www.ggf.org/dataformat1" 
[OK]
p20: "http://www.ggf.org/dataforma2"
-> "http://www.ggf.org/dataformat2" 
[OK]
p20: "Data access collects" -> "The data access interface collects" 
[OK]
Figures 3 and 4 captions: state that the examples use the WS-DAIR
specialisation 
[OK]
Section 5.3.2: "Returns the core property document values associated
with the service implementing this message." -> "Returns a copy of
the core property document associated with the service implementing
this message." 
[OK]
p24: "MAY contain URI" -> "MAY contain a URI" 
[OK]
Order all fault messages consistently. I would suggest: 
-InvalidResourceName 
-DataResourceUnavailable Parameter faults in the order the parameters 
 appear in the request.
-DatasetTooLargeFault where appropriate 
-NotAuthorizedFault 
-ServiceBusyFault 
[OK]
p24: "Relational Database" -> "relational database" 
[OK]
References: Ensure all references provide the status of the standard
and are up-to- date. (OGSA, OGSA Glossary, WS-Addressing,
WS-Agreement, WS-AtomicTransaction (check placement in order))
[OK]
Update WS-DAIR and WS-DAIX to be the companion version to this
document. 
[OK]

WS-DAIR
-------

I believe that once the issues with retrieving answers through the
SQLResponse interface are resolved...

Major Issues

A definition of a rowset resource is missing from Section 3.
[
If we're being consistent then, we'd also need to define the
SQLResponse resource.
]
Section 5.1.1 extends the WS-DAI core property document that states
all properties MUST be present. Does this apply to the schema element?
In the example property document in Section 5.3 it would be desirable
to see a schema being expressed.
[
If we address the WS-DAI issue then that addresses this in part.
Do we want to make this a MUST property or a MAY property?
Do we have an example schema element to hand?
]
I would suggest defining common return types, e.g. SQLDataset, once
and then reusing, as there are some minor inconsistencies
currently. 
[OK]
Also, how many datasets can be returned, one or many? If it
is the latter, then make GetSQLRowset operation consistent with
GetSQLUpdateCount. Note that the WSDL only seems to permit a single
dataset to be returned. If this is the case, then the explanation text
at the end of Section 6.4.2 should be revised to only return a single
Rowset, not two as is currently the case. Also, if only a single
Rowset can be returned, then the position and count parameters should
be removed from the GetSQLRowset operation. 
[
GetSQLUpdateCount is consistent with GetSQLRowset in terms of
arguments name, position and count. They differ in that GetSQLRowset
takes DatasetFormatURI since we're returning actual data.

GetSQLRowset can return N rowsets.

However, the text/WSDL (Appendix B.2 - SQLResponse WSDL) is
inconsistent in how different types of SQLResonseItem are treated
e.g. GetSQLResponseItemRequest, GetSQLRowSetRequest,
GetSQLUpdateCountRequest all take 

<xsd:element maxOccurs="1" minOccurs="1" name="Position" type="xsd:unsignedInt"/> 
<xsd:element maxOccurs="1" minOccurs="0" name="Count" type="xsd:unsignedInt"/>
so are consistent. 
GetSQLUpdateCountResponse
returns
<xsd:element maxOccurs="unbounded" minOccurs="1" name="UpdateCount"
 type="xsd:int"/> 
but GetSQLResponseItemResponse returns
<xsd:element maxOccurs="1" minOccurs="1" ref="wsdair:SQLDataset"/>
and GetSQLRowsetResponse returns 
<xsd:element maxOccurs="1" minOccurs="1" ref="wsdai:Dataset"/>
which is inconsistent. I think the above maxOccurs should be adjusted
to unbounded for consistency.
]
I have major concerns around the "Readable" and "Writeable" settings
applied to SQLResponse resources and SQLRowset resources. All the
examples show that both types of these are "Readable" and
"Writeable". However, neither supports query operations or any other
operations for setting the data. 
Note that "Readable" means that the resource can be queried as defined
in WS-DAI Core. 
[
SQLResponse and SQLRowset do support getters all of which get the
contents of these resources - and so get thr data.
A WS-DAI service supports GenericQuery which could be implemented for
these resources to support updates so these settings are valid.
]
In Section 6.3, the same operation is defined in the DatasetMap and
the ConfigurationMap. This means that it can operate in both the
direct and indirect modes. However, this requires different
parameters.
[
GetSQLRowset which appears in both. I think the second occurrence, in
ConfigurationMap, is a typo and should be GetSQLRowsetFactory.
]
For the factory operation, GetSQLRowsetFactory, why are there position
and count parameters. This puts it at odds with other factory methods,
and does not seem to provide any advantage. I would suggest dropping
them. This would not affect the return type.
[
This operation creates an SQLRowSet resource from an
SQLResponse resource. An SQLResponse may hold 0 or more row sets. So
the client needs to specify the Position of the row set in the
SQLResponse. Though, yes, the Count parameter is not needed.

Otherwise I don't think that specifying the Position is a problem, nor
the inconsistency in factory methods is a problem - how a resource is
created depends upon both the parent resource and the child so there
can't be a single generic factory operation.
]
Why does the example property document in Section 7.3 have a
configuration map section since there are no factory operations? 
[
Not sure. Is this just a copy-and-paste error?
]
Why is the dataset format in the response to at GetTuples message
optional? All other similar operations have this as a required
parameter, and this would ensure that the response is self
describing. 
[
Agree, this should be added.
]

Minor Issues

The document number is stated as GFD-R.076. In the section "Status
of This Memo" it states, "This document obsoletes GFD-R.076". I
suggest that you correct this to avoid any confusion. 
[OK]
Abstract: "regular web services environments" -> "regular web service
environments" 
[OK]
p6: provide references for SQL ISO standard and CIM model
[OK]
Example property document Section 5.3:
-Why are there three language map entries with the same information?
[
Think one should be SQLExecuteFactory? And one should be deleted.
]
-Has the language URI of the generic query language map been cut off?
[
This is Word wrapping. The closing element is on the next line.
]
-Why does the generic query operation not appear in the dataset map?
[
Good point.
]
-I would like to see an example schema expressed.
[
See earlier comment.
]
p8: "the SQLExpression used" -> "the type of SQLExpression used"
[OK]
All getPropertyDocument messages should be described with the
following form: "Returns a copy of the XXX property document." 
[OK]
Start of Sections 5, 6, and 7 should provide a brief
overview/description of the service. 
[OK]
Order all fault messages consistently. I would suggest:
-InvalidResourceName 
-DataResourceUnavailable 
-Parameter faults in the order the parameters appear in the request
-DatasetTooLargeFault where appropriate
-NotAuthorizedFault 
-ServiceBusyFault
[OK]
p16: "query present in the" -> "query presented in the"
[OK]
p17: "of the return rowset" -> "of the returned rowset"
[OK]
For text describing messages in Section 6.4.3, 6.4.4, and 6.4.6: "Get
a" -> "Get one or more" 
[OK]
Throughout ensure that "belong" -> "beyond" when referring to the
count fault 
[OK]
p20: "Get a Reference" -> "Get a reference"
[OK]
Move Figure 3 to start of Section 6.5 where it is discussed.
[OK]
p21: "representation of [J" -> "representation of Webrowset [J"
[OK]
Section 7.1.2 heading: "NoOfRows" -> "NumberOfRows" affects
operation name 
[OK]
Move Section 7.1.3 to after all definitions of properties. Make it into its 
own subsection,  i.e. 7.3.
[OK]
References: Ensure all references provide the status of the standard
and are up-to- date. (CIM, OGSA, OGSA Glossary (check placement in
order))
[OK]
Update WS-DAI Core to be the companion version to this document.
[OK]