[dais-wg] Updates Based on DAIS Factory Results

[Malcolm Atkinson]

It would seem to me to be a very odd semantics that allowed update of a
result set.  The result set may be incrementally instantiated much later
as it is read - what would an update mean?

Malcolm
 

 >-----Original Message-----
 >From: owner-dais-wg at ggf.org [mailto:owner-dais-wg at ggf.org] On 
 >Behalf Of Norman Paton
 >Sent: 23 May 2005 14:31
 >To: dais-wg at ggf.org
 >Subject: [dais-wg] Updates Based on DAIS Factory Results
 >
 >
 >The DAIS specifications support Factory operations, which return 
 >identifiers for
 >the results of queries.  However, there is a lack of symmetry in the 
 >handling of
 >such results in the specs, in that their identifiers cannot 
 >currently be 
 >provided
 >as inputs to update operations.  This note comments on options for 
 >extending this
 >capability. 
 >
 >1. Relational
 >
 >In the relational model, data access and manipulation 
 >requests are directed
 >at data services using the SQLAccess operation.  Additional 
 >operations could
 >be defined on the relational data access service or on the 
 >SQLRowSet that
 >in some way push the contents of the row set to the 
 >relational data access
 >service.
 >
 >1.1 Insert
 >
 >The following operation could be defined:
 >
 >SQLAccess::Insert(TableName, FieldMapping, RowsetIdentifier) -> 
 >SQLExecuteResponse
 >
 >Given the name of a table, insert the tuples from the rowset into the 
 >given table.
 >
 >Faults:
 >- Unable to access Rowset.
 >
 >The semantics might most easily be assumed to be those of the 
 >existing 
 >SQL clause:
 >
 >insert into TableName [(FieldName1 [, FieldName2, ...])] SelectClause
 >
 >where the SelectClause is assumed to range over the tuples in the 
 >RowSet.  The
 >SQLExecuteResponse provides access to the SQLCommunicationsArea, and 
 >thus is able
 >to provide access to a wide range of error conditions.
 >
 >The FieldMapping would represent a list of pairs, associating 
 >each named 
 >field in
 >TableName with each of the fields in the SQLRowSetSchema; it could be 
 >optional if
 >the names in the two settings had a 1:1 mapping.
 >
 >
 >1.2 Delete
 >
 >The following operation could be defined:
 >
 >SQLAccess::Delete(TableName, FieldMapping, RowsetIdentifier) -> 
 >SQLExecuteResponse
 >
 >Given the name of a table, delete the tuples from the rowset from the 
 >given table.
 >
 >Faults:
 >- Unable to access Rowset.
 >
 >The semantics might most easily be assumed to be those of the 
 >existing 
 >SQL clause:
 >
 >delete from TableName WHERE <condition>
 >
 >where the condition is assumed to test for tuples that match those in 
 >the RowSet,
 >given the name mapping in FieldMapping.  The match should probably 
 >involve equality
 >on all attributes, but matching only on key is also an option. 
 >SQLExecuteResponse
 >provides access to the SQLCommunicationsArea, and thus is able to 
 >provide access
 >to a wide range of error conditions.
 >
 >The FieldMapping would represent a list of pairs, associating 
 >each named 
 >field in
 >TableName with each of the fields in the SQLRowSetSchema; it could be 
 >optional if
 >the names in the two settings had a 1:1 mapping.
 >
 >
 >2. XML
 >
 >Unlike the WS-DAIR specification, the WS-DAIX spec contains top-level 
 >update operations,
 >namely:
 >
 >XMLCollectionAccess::AddDocuments([Name, Collection, Data]) -> 
 >ResponseDocument
 >XMLCollectionAccess::RemoveDocuments([Name], Collection) -> 
 >ResponseDocument
 >XMLCollectionAccess::BulkLoad([Collections],[Name, 
 >Collection, Data]) -> 
 >ResponseDocument
 >
 >Where the above operations take Data as a parameter (for 
 >insertion only 
 >- deletes are
 >by document name, which seems more natural than by document 
 >matching), 
 >one could
 >envisage variants in which an XMLSequenceIdentifier is passed as a 
 >parameter.
 >
 >
 >Anyway, these are some initial thoughts on how the named 
 >results of DAIS 
 >factory operations
 >might be able to be used as inputs to other DAIS operations; comments 
 >invited. 
 >
 >Norman
 >
 >
 >