head	1.32;
access;
symbols;
locks; strict;
comment	@# @;


1.32
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.31;

1.31
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.30;

1.30
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.29;

1.29
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.28;

1.28
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.27;

1.27
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.26;

1.26
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.25;

1.25
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.24;

1.24
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.23;

1.23
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.22;

1.22
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.21;

1.21
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.20;

1.20
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.19;

1.19
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.18;

1.18
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.17;

1.17
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.16;

1.16
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.15;

1.15
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.14;

1.14
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.13;

1.13
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.12;

1.12
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.11;

1.11
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.10;

1.10
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.9;

1.9
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.8;

1.8
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.7;

1.7
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.6;

1.6
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.5;

1.5
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.4;

1.4
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.3;

1.3
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.2;

1.2
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	1.1;

1.1
date	2007.01.09.00.00.00;	author MoinMoin;	state Exp;
branches;
next	;


desc
@Initial revision
@


1.32
log
@Revision 32
@
text
@---+ FourthProposal

---+++++ General strategy
Based on the SecondProposal and the BerlinMeetingResults develop a new proposal to accomodate all of the suggested changes. Still indicating open or problematic issues.

---+++++ Files

   * *old protocol schema based on the BerlinMeetingResults* :
   http://www.bgbm.org/biodivinf/Schema/protocol4.xsd


---+++++ Ideas included not part of the BerlinMeetingResults
   * FilterEncoding
   * allow comparative operators to compare any 2 expressions, which can be made of literals (values) or concepts. This would allow to compare 2 concepts also instead of the current restriction to compare a concept with a literal only.
   * Remove the CustomSearch from the protocol. See the SearchProposalTwo for details of the SearchRequest.
   * The RecordDefinition is removed from the request and is thought of being inherent to each ConceptualSchema. A list of RecordDefinitions can now be retrieved by the CapabilitiesRequest (see CapabilitiesProposalFour).
   * capabilities response definition seperated for providers and datasources (see CapabilitiesProposalFour)
      * a provider can return allowed request types and a flag to indicate whether he accepts requests for multiple datasources
   * response content element not repeatable anymore, because merging of responses will not take place. Multiple sets of metadata and acompanying records are now grouped by a repeatable recordset element.
      * see SearchResponseTopStructure
   * footer included to hold paging information that was called totals before. It needs to count records for the whole content and not for recordsets only as proposed.
   * add element "responses" for providers or portals to wrap single responses. Provider access points should always use this for responding even a single response document from one datasource.
   * changed header information to fit the HeaderProposalTwo. Mainly assigning a destination only to one accesspoint while allowing to address several datasources.
@


1.31
log
@Revision 31
@
text
@a6 4
The schema for this proposal includes all the additional suggestions giving below unless otherwise stated.

   * *Latest protocol schemas based on all additional suggestions below* :
   http://ww3.bgbm.org/moin/protocol/documents/protocol.zip
a23 36

-----
*comments:*
  None so far...
-----

---++ Additional Suggestions
The following suggestions are included in the schema files below. We will base the recommendation and specification on this but know some of the ideas will be a bit "revolutionary" and are in need of further discussion and probably even testing by a reference implementation.

Please DO COMMENT on them !

---+++++ Simple Issues
   * remove <type> element from the header and make the element following the header specify the kind of request. This allows validation of a request and response in contrast to NO validation using values in the header element.

---+++++ Webservice Entities
We think the protocol is in its present form serving different kind of services which forces us to laxly define the protocol to accomodate requests and responses of DatasourceServices, ProviderServices and what we would like to call MessageBrokerServices. To have a more specific protocol we are defining a seperate protocol with its own namespace for each of the respective service types. These protocols are very similar to each other and are therefore based on a common core protocol schema.

In the protocol specification we are considering DatasourceServices and ProviderServices as a limited form of MessageBrokerServices only. Following are some special features for each of them:

*DatasourceService specific*
   * No destination in the header
   * A response to a CapabilitiesRequest specific for the single datasource only as given in the DatasourceCapabilitiesProposal
   * The MetadataRequest is returning only metadata about the datasource and its "bussiness" entity in the UDDI sense. Nothing about a provider service, just about the business entity in the sense of a real world organisation. See the DatasourceMetadataProposal for an example.

*ProviderService specific*
   * optionally listing addressed datasources in the header. If none is mentioned the request should by default be passed on to all available local datasources.
   * All requests are passed on to the requested datasources. EXCEPT:
      * A PingRequest is never relayed to other services and will always be answered directly by the ProviderService.
   * The MetadataRequest is only pooling the metadata responses from the datasources. A ProviderService does not have its own metadata or capabilities.

---+++++ Record FourthProposal Document based approach
A very essential discussion is whether the protocol is record/object based or document based.
Please see the RecordVsDocumentApproach discussion for this.

Until we can decide for one of them - which may take some time and even a test implementation - we propose to include both approaches as 2 different request types in a common protocol.
The record based one will simply be called "search" as in the proposals before and additionally there is now a search request called "docsearch" that works on a document basis. See the DocSearchProposal for more details.
@


1.30
log
@Revision 30
@
text
@d63 1
a63 1
The record based one will simply be called "search" as in the proposals before and additionally there is now a search request called "docsearch" that works on a document basis. See DocSearch for more details.
@


1.29
log
@Revision 29
@
text
@d10 1
a10 1
[[br]] http://ww3.bgbm.org/moin/protocol/documents/protocol.zip
d12 2
a13 2
   * *protocol schema based on the BerlinMeetingResults* :
[[br]] http://www.bgbm.org/biodivinf/Schema/protocol4.xsd
@


1.28
log
@Revision 28
@
text
@d9 6
a14 1
   * *Protocol Schema* : http://www.bgbm.org/biodivinf/Schema/protocol4.xsd
a63 6



---+++++ Files
   * *Protocol Schemas* : http://ww3.bgbm.org/moin/protocol/documents/protocol.zip

@


1.27
log
@Revision 27
@
text
@d26 2
a27 1

@


1.26
log
@Revision 26
@
text
@d14 2
a15 1
   * Remove the CustomSearch from the protocol. See the RecordSearchProposal for the details for the SearchRequest.
@


1.25
log
@Revision 25
@
text
@d14 1
@


1.24
log
@Revision 24
@
text
@d57 2
@


1.23
log
@Revision 23
@
text
@d58 1
a58 1
   * *Protocol Schemas* : [http://ww3.bgbm.org/protocolwiki/documents/protocol.zip]
@


1.22
log
@Revision 22
@
text
@d58 2
a59 1
   * *Protocol Schemas* : http://ww3.bgbm.org/protocolwiki/documents/protocol.zip
@


1.21
log
@Revision 21
@
text
@d58 1
a58 1
   * *Protocol Schemas* : http://www.bgbm.org/biodivinf/Schema/newprotocol.zip
@


1.20
log
@Revision 20
@
text
@d55 1
a55 1
The record based one will simply be called "search" as in the proposals before and additionally there is now a search request called DocSearch that works on a document basis. See DocSearch for more details.
@


1.19
log
@Revision 19
@
text
@d54 1
a54 1
Until it is decided which is appropiate, we include both approaches as 2 different request types.
@


1.18
log
@Revision 18
@
text
@a49 1

@


1.17
log
@Revision 17
@
text
@d40 3
a42 3
   * no destination in the header
   * a response to a CapabilitiesRequest specific for the single datasource only as given in the DatasourceCapabilitiesProposal
   * the MetadataRequest is returning only metadata about the datasource and its provider??? Shouldnt it only return metadata about itself and its business entity in the UDDI sense? nothing about a provider service, just about the business entity in the sense of a real world organisation. See the DatasourceMetadataProposal for an example.
d48 1
a48 2
   * ??? Does a ProviderService really need its own metadata or capabilities? Probably only the datasource metadata and capabilities are relevant to anyone.
   * ??? A new request type could be nice to simply retrieve a list of other known services without asking for their metadata. On the other hand the metadata request solves this already.
d55 3
@


1.16
log
@Revision 16
@
text
@d53 2
a54 1

@


1.15
log
@Revision 15
@
text
@d31 2
a51 1

@


1.14
log
@Revision 14
@
text
@d47 1
a47 1
   * ??? A new RequestType could be nice to simply retrieve a list of other known services without asking for their metadata. On the other hand the metadata request solves this already.
@


1.13
log
@Revision 13
@
text
@d39 1
a39 1
   * a CapabilitiesResponse specific for the single datasource only as given in the DatasourceCapabilitiesProposal
d43 5
@


1.12
log
@Revision 12
@
text
@d33 1
a33 1
We think the protocol is in its present form serving different kind of services which forces us to laxly define the protocol to accomodate requests and responses of DatasourceServices, ProviderServices and what we would like to call MessageBrokerServices. To have a more specific protocol we are defining a seperate protocol with its own namespace for each of the respective service types. These protocols are very alike and are based on a common core protocol schema library.
d35 8
@


1.11
log
@Revision 11
@
text
@d11 1
a11 1
---+++++ Additional Suggestions
d25 18
@


1.10
log
@Revision 10
@
text
@d21 4
@


1.9
log
@Revision 9
@
text
@d20 1
@


1.8
log
@Revision 8
@
text
@d19 1
@


1.7
log
@Revision 7
@
text
@d17 1
@


1.6
log
@Revision 6
@
text
@d14 1
a14 1
   * capabilities response definition seperated for providers and datasources (see CapabilitiesProposalTwo)
@


1.5
log
@Revision 5
@
text
@d14 1
a14 1
   * capabilities response definition seperated for providers and datasources
@


1.4
log
@Revision 4
@
text
@d7 2
a10 3
---+++++ Details
 ...

d14 4
@


1.3
log
@Revision 3
@
text
@d14 1
a14 1
      * allow comparative operators to compare any 2 expressions, which can be made of literals (values) or concepts. This would allow to compare 2 concepts also instead of the current restriction to compare a concept with a literal only.
@


1.2
log
@Revision 2
@
text
@d11 4
@


1.1
log
@Initial revision
@
text
@d3 2
a4 2
---+++++ Schema File
gfd
d6 5
@