1220 lines
25 KiB
Plaintext
1220 lines
25 KiB
Plaintext
|
head 1.63;
|
||
|
|
access;
|
||
|
|
symbols;
|
||
|
|
locks; strict;
|
||
|
|
comment @# @;
|
||
|
|
|
||
|
|
|
||
|
|
1.63
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.62;
|
||
|
|
|
||
|
|
1.62
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.61;
|
||
|
|
|
||
|
|
1.61
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.60;
|
||
|
|
|
||
|
|
1.60
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.59;
|
||
|
|
|
||
|
|
1.59
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.58;
|
||
|
|
|
||
|
|
1.58
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.57;
|
||
|
|
|
||
|
|
1.57
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.56;
|
||
|
|
|
||
|
|
1.56
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.55;
|
||
|
|
|
||
|
|
1.55
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.54;
|
||
|
|
|
||
|
|
1.54
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.53;
|
||
|
|
|
||
|
|
1.53
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.52;
|
||
|
|
|
||
|
|
1.52
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.51;
|
||
|
|
|
||
|
|
1.51
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.50;
|
||
|
|
|
||
|
|
1.50
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.49;
|
||
|
|
|
||
|
|
1.49
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.48;
|
||
|
|
|
||
|
|
1.48
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.47;
|
||
|
|
|
||
|
|
1.47
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.46;
|
||
|
|
|
||
|
|
1.46
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.45;
|
||
|
|
|
||
|
|
1.45
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.44;
|
||
|
|
|
||
|
|
1.44
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.43;
|
||
|
|
|
||
|
|
1.43
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.42;
|
||
|
|
|
||
|
|
1.42
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.41;
|
||
|
|
|
||
|
|
1.41
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.40;
|
||
|
|
|
||
|
|
1.40
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.39;
|
||
|
|
|
||
|
|
1.39
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.38;
|
||
|
|
|
||
|
|
1.38
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.37;
|
||
|
|
|
||
|
|
1.37
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.36;
|
||
|
|
|
||
|
|
1.36
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.35;
|
||
|
|
|
||
|
|
1.35
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.34;
|
||
|
|
|
||
|
|
1.34
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.33;
|
||
|
|
|
||
|
|
1.33
|
||
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.32;
|
||
|
|
|
||
|
|
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.63
|
||
|
|
log
|
||
|
|
@Revision 63
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@---+ Second proposal
|
||
|
|
|
||
|
|
---+++++ General strategy
|
||
|
|
|
||
|
|
To eliminate all DifferencesBetweenProtocols, by either adopting the approach used by one of them, or by suggesting a new approach. This should be mainly a straightforward and conservative proposal, although new features could be added.
|
||
|
|
|
||
|
|
---+++++ Files
|
||
|
|
* *Protocol Schema* : http://www.bgbm.org/biodivinf/Schema/protocol2.xsd
|
||
|
|
|
||
|
|
---+++++ Details
|
||
|
|
|
||
|
|
* Use the same approach regarding AccessPoints:
|
||
|
|
* Each provider and each resource will have its own access point.
|
||
|
|
* Providers will only accept metadata and capabilities requests. (*open issue*)
|
||
|
|
* Resources will accept all kind of requests.
|
||
|
|
* Providers will answer metadata requests including metadata about themselves and about all its resources.
|
||
|
|
* Resources will answer metadata requests including metadata about themselves and about their providers.
|
||
|
|
|
||
|
|
* Eliminate DifferencesInHeaderInformation by (see HeaderProposalOne):
|
||
|
|
|
||
|
|
* removing the optional attribute "resource" in both "source" and "destination" elements (affects DiGIR). (*open issue*)
|
||
|
|
* changing the "version" element to multiple "software" elements (with attributes "name" and "version"). "Software" could have multiple occurrences (related to provider, portal, indexer, client, etc), and each "software" could have "components" as subelements (also with name and version). This could be important not only for debugging and logging, but mainly for determining which protocols are supported by a provider (affects both - related to new BioCASE proposal). (*move this to capabilities SecondProposal diagnostics in case of error)*
|
||
|
|
* allowing multiple "source" elements to be able to track each address in the process, and incorporating the "sendTime" element as an attribute of "source" (affects both - related to new BioCASE proposal).
|
||
|
|
* *Pending issue: *should we remove the "type" element and only use the immediate element after "header" to determine the type of requests/responses?
|
||
|
|
|
||
|
|
* Eliminate DifferencesInRequestTypes by:
|
||
|
|
* Including a MetadataRequest SecondProposal Response (affects BioCASE).
|
||
|
|
* Defining the metadata elements in a separate schema (affects both).
|
||
|
|
* Including a CapabilitiesRequest SecondProposal Response (affects DiGIR).
|
||
|
|
* Including a PingRequest SecondProposal Response (affects both).
|
||
|
|
|
||
|
|
* Use the same metadata response based on DiGIR with a few changes: (see MetadataProposalOne)
|
||
|
|
* Removing the implementation element (duplicated).
|
||
|
|
* Moving the elements conceptualSchema, minQueryTermLength, maxSearchResponseRecords, maxInventoryResponseRecords to the CapabilitiesRequest.
|
||
|
|
* Removing recordBasis and recordIdentifier elements.
|
||
|
|
* Including accessPoint in the resource.
|
||
|
|
* Moving code and contact from host to provider.
|
||
|
|
* Removing host element.
|
||
|
|
* Changing useRestrictions to IPR. *Pending issue: *is IPR broader than useRestrictions?
|
||
|
|
* *Pending issue: *do we need to keep numberOfRecords? (could be retrieved through count).
|
||
|
|
|
||
|
|
* Use the same CapabilitiesRequest and Response: (see CapabilitiesProposalOne)
|
||
|
|
* Including a list of conceptual schemas being used (and all mapped concepts).
|
||
|
|
* Including a list of request methods supported.
|
||
|
|
* Including a list of local configurations (minQueryTermLength, maxSearchResponseRecords, maxInventoryResponseRecords). *Pending issue: *should the possible configuration names be defined inside the protocol or should we use a generic element for that?
|
||
|
|
|
||
|
|
* Eliminate DifferencesInConceptualBinding by: (see ConceptualBindingProposalOne)
|
||
|
|
* Referencing concepts through simple xpaths (affects DiGIR).
|
||
|
|
* Allowing concepts from different conceptual schemas to be present in the same request by prefixing the path (affects mainly BioCASE).
|
||
|
|
|
||
|
|
* Use the same SearchRequest by:
|
||
|
|
* Allowing 3 subtypes of searches (which could be supported or not by the providers):
|
||
|
|
* A FullDocumentSearch that just references an XML schema defining the concepts involved, how they should be structured in the response, and what are the mandatory concepts (affects DiGIR).
|
||
|
|
* A PartialDocumentSearch that references one or more concepts from a generic XML schema. The schema specifies the structure, and all mandatory concepts from the schema should be returned too (affects DiGIR and BioCASE).
|
||
|
|
* A CustomDocumentSearch based on a ResponseStructure (affects BioCASE).
|
||
|
|
* Alternative proposal: SearchRequestProposalTwo
|
||
|
|
|
||
|
|
* Use the same ResponseStructure specification for a CustomSearch by: (see CustomSearchProposalOne)
|
||
|
|
* Allowing values to be returned as attributes.
|
||
|
|
* Allowing element/attribute name specification to appear in responses (including prefix).
|
||
|
|
* Allowing use of concepts from different schemas in the same structure.
|
||
|
|
* Allowing record definitions in the record structure (for count and paging purposes).
|
||
|
|
* *Pending issue: *could we somehow deal with recursive relationships between concepts, i.e. unlimited depth nesting? (SDD seems to use that)
|
||
|
|
* *Pending issue: *should we try to allow the specification of data dictionaries so that elements in the response could reference entries in thess dictionaries and avoid value repetition? (SDD seems to use this approach)
|
||
|
|
|
||
|
|
* Use the same InventoryRequest and Response: (see InventoryProposalOne)
|
||
|
|
* Allowing filters (affects BioCASE).
|
||
|
|
* Allowing counts, both partial and total (affects BioCASE).
|
||
|
|
* Using the name "inventory" for this type of request (affects BioCASE).
|
||
|
|
|
||
|
|
* Eliminate DifferencesWithOperators by:
|
||
|
|
* adding a new unary logical operator called "not" (affects DiGIR).
|
||
|
|
* adding a new unary comparative operator called "isNull" (affects DiGIR).
|
||
|
|
* dropping the operators "orNot", "andNot" and "notEquals" (affects both).
|
||
|
|
* dropping the operator "isNotNull" (affects BioCASE).
|
||
|
|
|
||
|
|
* Use the same way to call providers:
|
||
|
|
* Using a single POST or GET parameter called "request" which contains either the XML message or an URL pointing to the XML message.
|
||
|
|
|
||
|
|
* *Pending issue: *How should we deal with NULL values when producing responses?
|
||
|
|
|
||
|
|
* Extra suggestions (not directly related to protocol integration):
|
||
|
|
* agree on common ErrorCodes and use a standard prefix for classification of codes.
|
||
|
|
* allow search requests without filters (affects both).
|
||
|
|
* change maxOccurs of LOPs to unbounded (affects both).
|
||
|
|
* include a new operator "isMapped" (affects both).
|
||
|
|
* allow more than one concept in inventory/scan requests (affects both). (see InventoryProposalTwo)
|
||
|
|
* include a PingRequest (affects both).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.62
|
||
|
|
log
|
||
|
|
@Revision 62
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d7 3
|
||
|
|
a88 15
|
||
|
|
|
||
|
|
---+++++ Files
|
||
|
|
|
||
|
|
* *Protocol Schema* : http://www.bgbm.org/biodivinf/Schema/protocol2.xsd
|
||
|
|
|
||
|
|
---+++++ Examples
|
||
|
|
|
||
|
|
* Capabilities Request SecondProposal Response
|
||
|
|
* Metadata Request SecondProposal Response
|
||
|
|
* Search
|
||
|
|
* Full Document Request SecondProposal Response
|
||
|
|
* Partial Document Request SecondProposal Response
|
||
|
|
* Custom Document Request SecondProposal Response
|
||
|
|
* Inventory Request SecondProposal Response
|
||
|
|
* Ping Request SecondProposal Response
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.61
|
||
|
|
log
|
||
|
|
@Revision 61
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@a78 2
|
||
|
|
* *Pending issue: *Agree on common ErrorCodes and use a standard prefix for classification of codes
|
||
|
|
|
||
|
|
d80 1
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.60
|
||
|
|
log
|
||
|
|
@Revision 60
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@a86 1
|
||
|
|
* *Pending issue: *should we include in the protocol header an optional "compression" element?
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.59
|
||
|
|
log
|
||
|
|
@Revision 59
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d84 1
|
||
|
|
a84 1
|
||
|
|
* *Pending issue: *should we accept an optional attribute _ignoreUnknownConcepts_ (default=false) in the filter? (affects both).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.58
|
||
|
|
log
|
||
|
|
@Revision 58
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d75 1
|
||
|
|
a75 1
|
||
|
|
* Using a single POST or GET parameter called "request" and containing either the XML message or an URL pointing to the XML message.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.57
|
||
|
|
log
|
||
|
|
@Revision 57
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@a40 1
|
||
|
|
* *Pending issue: *Would it make sense to include a list of protocols (and versions) supported by the provider? Or maybe we could have a central repository with this information? (could also be discussed later during the topic "dealing with different protocol versions")
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.56
|
||
|
|
log
|
||
|
|
@Revision 56
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d20 1
|
||
|
|
a20 1
|
||
|
|
* allowing multiple "source" elements to be able to track each address in the process, and incorporating the "sendTime" element as an attribute of "source" (affects both - related to new BioCASE proposal). *Pending issue: *to retrieve the original source (usually the most important) we could figure out a different way of emphasizing it instead of getting the "source" with the earliest "sendTime" (it seems one cannot rely on the order of elements when using some DOM parsers).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.55
|
||
|
|
log
|
||
|
|
@Revision 55
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d19 1
|
||
|
|
a19 1
|
||
|
|
* changing the "version" element to multiple "software" elements (with attributes "name" and "version"). "Software" could have multiple occurrences (related to provider, portal, indexer, client, etc), and each "software" could have "components" as subelements (also with name and version). This could be important not only for debugging and logging, but mainly for determining which protocols are supported by a provider (affects both - related to new BioCASE proposal).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.54
|
||
|
|
log
|
||
|
|
@Revision 54
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d18 1
|
||
|
|
a18 1
|
||
|
|
* removing the optional attribute "resource" in both "source" and "destination" elements (affects DiGIR).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.53
|
||
|
|
log
|
||
|
|
@Revision 53
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d11 2
|
||
|
|
a12 2
|
||
|
|
* Providers will only accept metadata and capabilities requests.
|
||
|
|
* Resources will accept all requests.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.52
|
||
|
|
log
|
||
|
|
@Revision 52
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d54 1
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.51
|
||
|
|
log
|
||
|
|
@Revision 51
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d77 2
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.50
|
||
|
|
log
|
||
|
|
@Revision 50
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d9 7
|
||
|
|
a22 7
|
||
|
|
* Use the same approach regarding AccessPoints:
|
||
|
|
* Each provider and each resource will have its own access point.
|
||
|
|
* Providers will only accept metadata and capabilities requests.
|
||
|
|
* Resources will accept all requests.
|
||
|
|
* Providers will answer metadata requests including metadata about themselves and about all its resources.
|
||
|
|
* Resources will answer metadata requests including metadata about themselves and about their providers.
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.49
|
||
|
|
log
|
||
|
|
@Revision 49
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@a13 1
|
||
|
|
* leaving the "compression" element suggested by BioCASE for the future (affects none).
|
||
|
|
d82 1
|
||
|
|
a82 1
|
||
|
|
* include optional attribute _ignoreUnknownConcepts_ (default=false) (affects both).
|
||
|
|
d85 1
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.48
|
||
|
|
log
|
||
|
|
@Revision 48
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d12 1
|
||
|
|
a12 1
|
||
|
|
* changing the "version" element to multiple "software" elements (with attributes "name" and "version"). "Software" could have multiple occurrences (related to provider, portal, indexer, client, etc), and each "software" could have "components" as subelements (also with name and version)(affects both - related to new BioCASE proposal).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.47
|
||
|
|
log
|
||
|
|
@Revision 47
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d9 1
|
||
|
|
a9 1
|
||
|
|
* Eliminate DifferencesInHeaderInformation by:
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.46
|
||
|
|
log
|
||
|
|
@Revision 46
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d12 1
|
||
|
|
a12 1
|
||
|
|
* allowing multiple "version" elements (with a new attribute "software") to be able to know the versions of more than one software involved in the whole process (affects both - related to new BioCASE proposal).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.45
|
||
|
|
log
|
||
|
|
@Revision 45
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d42 1
|
||
|
|
a42 1
|
||
|
|
* Including a list of protocols supported (and all versions).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.44
|
||
|
|
log
|
||
|
|
@Revision 44
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d46 4
|
||
|
|
a55 4
|
||
|
|
* Eliminate DifferencesInConceptualBinding by: (see ConceptualBindingProposalOne)
|
||
|
|
* Referencing concepts through simple xpaths (affects DiGIR).
|
||
|
|
* Allowing concepts from different conceptual schemas to be present in the same request by prefixing the path (affects mainly BioCASE).
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.43
|
||
|
|
log
|
||
|
|
@Revision 43
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@a45 10
|
||
|
|
* Eliminate DifferencesWithOperators by:
|
||
|
|
* adding a new unary logical operator called "not" (affects DiGIR).
|
||
|
|
* adding a new unary comparative operator called "isNull" (affects DiGIR).
|
||
|
|
* dropping the operators "orNot", "andNot" and "notEquals" (affects both).
|
||
|
|
* dropping the operator "isNotNull" (affects BioCASE).
|
||
|
|
|
||
|
|
* Eliminate DifferencesInConceptualBinding by: (see ConceptualBindingProposalOne)
|
||
|
|
* Referencing concepts through simple xpaths (affects DiGIR).
|
||
|
|
* Allowing concepts from different conceptual schemas to be present in the same request by prefixing the path (affects mainly BioCASE).
|
||
|
|
|
||
|
|
d52 4
|
||
|
|
d69 6
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.42
|
||
|
|
log
|
||
|
|
@Revision 42
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d75 4
|
||
|
|
a78 1
|
||
|
|
* Agree on common ErrorCodes and use a standard prefix for classification of codes
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.41
|
||
|
|
log
|
||
|
|
@Revision 41
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d17 1
|
||
|
|
a17 2
|
||
|
|
* Use the same approach regarding AccessPoints: (see discussion in ProtocolFeatures/AccessPoint)
|
||
|
|
|
||
|
|
a24 1
|
||
|
|
|
||
|
|
a30 1
|
||
|
|
|
||
|
|
a40 1
|
||
|
|
|
||
|
|
a46 1
|
||
|
|
|
||
|
|
a62 1
|
||
|
|
|
||
|
|
a70 1
|
||
|
|
|
||
|
|
a77 1
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.40
|
||
|
|
log
|
||
|
|
@Revision 40
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d17 8
|
||
|
|
a31 8
|
||
|
|
* Use the same approach regarding access points: (see discussion in ProtocolFeatures/AccessPoint)
|
||
|
|
|
||
|
|
* Each provider and each resource will have its own access point.
|
||
|
|
* Providers will only accept metadata and capabilities requests.
|
||
|
|
* Resources will accept all requests.
|
||
|
|
* Providers will answer metadata requests including metadata about themselves and about all its resources.
|
||
|
|
* Resources will answer metadata requests including metadata about themselves and about their providers.
|
||
|
|
|
||
|
|
d61 6
|
||
|
|
a75 6
|
||
|
|
* Use the same SearchRequest by:
|
||
|
|
* Allowing 3 subtypes of searches (which could be supported or not by the providers):
|
||
|
|
* A FullDocumentSearch that just references an XML schema defining the concepts involved, how they should be structured in the response, and what are the mandatory concepts (affects DiGIR).
|
||
|
|
* A PartialDocumentSearch that references one or more concepts from a generic XML schema. The schema specifies the structure, and all mandatory concepts from the schema should be returned too (affects DiGIR and BioCASE).
|
||
|
|
* A CustomDocumentSearch based on a ResponseStructure (affects BioCASE).
|
||
|
|
|
||
|
|
d82 2
|
||
|
|
d88 1
|
||
|
|
a88 1
|
||
|
|
* include optional attribute _ignoreNotMappedConcepts_ (default=false) (affects both).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.39
|
||
|
|
log
|
||
|
|
@Revision 39
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d98 4
|
||
|
|
a101 1
|
||
|
|
* Search Request SecondProposal Response
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.38
|
||
|
|
log
|
||
|
|
@Revision 38
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d32 1
|
||
|
|
a32 1
|
||
|
|
* Use the same metadata response based on DiGIR with a few changes: (see MetadataResponseProposalOne)
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.37
|
||
|
|
log
|
||
|
|
@Revision 37
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d61 1
|
||
|
|
a61 1
|
||
|
|
* Use the same ResponseStructure specification for a CustomSearch by: (see ResponseStructureProposalOne)
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.36
|
||
|
|
log
|
||
|
|
@Revision 36
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d48 1
|
||
|
|
a48 1
|
||
|
|
* Including a list of local configurations (minQueryTermLength, maxSearchResponseRecords, maxInventoryResponseRecords).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.35
|
||
|
|
log
|
||
|
|
@Revision 35
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d71 4
|
||
|
|
a74 4
|
||
|
|
* Allowing 3 subtypes of searches:
|
||
|
|
* A FullDocumentSearch
|
||
|
|
* A PartialDocumentSearch
|
||
|
|
* A CustomDocumentSearch
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.34
|
||
|
|
log
|
||
|
|
@Revision 34
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d70 5
|
||
|
|
a74 3
|
||
|
|
* Eliminate remaining DifferencesInSearchOperations by:
|
||
|
|
|
||
|
|
* ...
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.33
|
||
|
|
log
|
||
|
|
@Revision 33
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d67 2
|
||
|
|
a78 1
|
||
|
|
* ...
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.32
|
||
|
|
log
|
||
|
|
@Revision 32
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d84 1
|
||
|
|
a84 1
|
||
|
|
* allow more than one concept in inventory/scan requests (affects both).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.31
|
||
|
|
log
|
||
|
|
@Revision 31
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d57 1
|
||
|
|
a57 1
|
||
|
|
* Use the same ConceptualBinding:
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.30
|
||
|
|
log
|
||
|
|
@Revision 30
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d72 1
|
||
|
|
a72 1
|
||
|
|
* Eliminate DifferencesInScanOperations by:
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.29
|
||
|
|
log
|
||
|
|
@Revision 29
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d61 1
|
||
|
|
a61 1
|
||
|
|
* Use the same ResponseStructure specification by: (see ResponseStructureProposalOne)
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.28
|
||
|
|
log
|
||
|
|
@Revision 28
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d43 1
|
||
|
|
a43 1
|
||
|
|
* Use the same capabilities response: (see CapabilitiesResponseProposalOne)
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.27
|
||
|
|
log
|
||
|
|
@Revision 27
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d19 1
|
||
|
|
a19 1
|
||
|
|
* Including a "metadata" request/response (affects BioCASE).
|
||
|
|
d21 2
|
||
|
|
a22 2
|
||
|
|
* Including a "capabilities" request/response (affects DiGIR).
|
||
|
|
* Including a "ping" request/response (affects both).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.26
|
||
|
|
log
|
||
|
|
@Revision 26
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d57 1
|
||
|
|
a57 2
|
||
|
|
* Eliminate DifferencesInConceptualBinding by: (see ConceptualBindingProposalOne)
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.25
|
||
|
|
log
|
||
|
|
@Revision 25
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@a56 7
|
||
|
|
* Eliminate DifferencesInScanOperations by:
|
||
|
|
|
||
|
|
* Allowing filters (affects BioCASE).
|
||
|
|
* Allowing counts, both partial and total (affects BioCASE).
|
||
|
|
* Using the name "inventory" for this type of request (affects BioCASE).
|
||
|
|
* ...
|
||
|
|
|
||
|
|
d69 11
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.24
|
||
|
|
log
|
||
|
|
@Revision 24
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d34 7
|
||
|
|
a40 7
|
||
|
|
* Removed implementation element (duplicated).
|
||
|
|
* Elements conceptualSchema, minQueryTermLength, maxSearchResponseRecords, maxInventoryResponseRecords were moved to the CapabilitiesRequest.
|
||
|
|
* Removed recordBasis and recordIdentifier elements.
|
||
|
|
* Included accessPoint in the resource.
|
||
|
|
* Moved code and contact from host to provider.
|
||
|
|
* Removed host element.
|
||
|
|
* useRestrictions was changed to IPR. *Pending issue: *is IPR broader than useRestrictions?
|
||
|
|
d64 1
|
||
|
|
a64 1
|
||
|
|
* Eliminate DifferencesInConceptualBinding by:
|
||
|
|
d69 6
|
||
|
|
a74 1
|
||
|
|
* To be continued...
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.23
|
||
|
|
log
|
||
|
|
@Revision 23
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d62 6
|
||
|
|
a67 1
|
||
|
|
*
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.22
|
||
|
|
log
|
||
|
|
@Revision 22
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d80 2
|
||
|
|
d84 1
|
||
|
|
a84 1
|
||
|
|
* Metadata Request SecondProposal Response
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.21
|
||
|
|
log
|
||
|
|
@Revision 21
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d72 1
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.20
|
||
|
|
log
|
||
|
|
@Revision 20
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d68 1
|
||
|
|
a68 1
|
||
|
|
* allow search requests without filters.
|
||
|
|
d70 2
|
||
|
|
a71 2
|
||
|
|
* include optional attribute _ignoreNotMappedConcepts_ (default=false).
|
||
|
|
* allow more than one concept in inventory/scan requests.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.19
|
||
|
|
log
|
||
|
|
@Revision 19
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d57 7
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.18
|
||
|
|
log
|
||
|
|
@Revision 18
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d5 1
|
||
|
|
a5 1
|
||
|
|
To eliminate all DifferencesBetweenProtocols, by either adopting the approach used by one of them, or by suggesting a new approach. This should be mainly a conservative proposal, although new features could be added.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.17
|
||
|
|
log
|
||
|
|
@Revision 17
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d41 1
|
||
|
|
a41 1
|
||
|
|
* *Pending issue: *do we need to keep numberOfRecords? (could be retrieved through count)
|
||
|
|
d43 6
|
||
|
|
a48 1
|
||
|
|
* Use the same capabilities response
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.16
|
||
|
|
log
|
||
|
|
@Revision 16
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d15 1
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.15
|
||
|
|
log
|
||
|
|
@Revision 15
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d13 1
|
||
|
|
a13 1
|
||
|
|
* allowing multiple "source" elements to be able to track each address in the process, and incorporating the "sendTime" element as an attribute of "source" (affects both - related to new BioCASE proposal). *Pending issue: *in order to retrieve the original source (usually the most important) we could figure out a different way of emphasizing it instead of getting the "source" with the earliest "sendTime" (it seems one cannot rely on the order of elements when using some DOM parsers).
|
||
|
|
d31 13
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.14
|
||
|
|
log
|
||
|
|
@Revision 14
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d23 8
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.13
|
||
|
|
log
|
||
|
|
@Revision 13
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d13 1
|
||
|
|
a13 1
|
||
|
|
* allowing multiple "source" elements to be able to track each address in the process, and incorporating the "sendTime" element as an attribute of "source" (affects both - related to new BioCASE proposal). *Pending issue: *in order to retrieve the original source (usually the most important) we could figure out a different way of emphasizing it instead of getting the "source" with the earliest "sendTime" (it seems one cannot rely on the order of elements when using some DOM parsers)
|
||
|
|
d15 8
|
||
|
|
a22 1
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.12
|
||
|
|
log
|
||
|
|
@Revision 12
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d13 2
|
||
|
|
a14 2
|
||
|
|
* allowing multiple "source" elements to be able to track the whole process, and incorporating the "sendTime" element as an attribute of "source" (affects both - related to new BioCASE proposal). *pending issue: *
|
||
|
|
* leaving the "compression" element to the future (affects none).
|
||
|
|
a15 1
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.11
|
||
|
|
log
|
||
|
|
@Revision 11
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d33 1
|
||
|
|
a33 1
|
||
|
|
---+++++ Examples (tbd)
|
||
|
|
d35 3
|
||
|
|
a37 1
|
||
|
|
* Protocol Schema: http://www.bgbm.org/biodivinf/Schema/protocol2.xsd
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.10
|
||
|
|
log
|
||
|
|
@Revision 10
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d35 1
|
||
|
|
a35 1
|
||
|
|
* Protocol Schema
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.9
|
||
|
|
log
|
||
|
|
@Revision 9
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d9 8
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.8
|
||
|
|
log
|
||
|
|
@Revision 8
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d9 1
|
||
|
|
a9 1
|
||
|
|
* Eliminate DifferencesWithOperators and simplify their construction:
|
||
|
|
d11 4
|
||
|
|
a14 4
|
||
|
|
* add a new unary logical operator called "not" (affects DiGIR).
|
||
|
|
* add a new unary comparative operator called "isNull" (affects DiGIR).
|
||
|
|
* drop the operators "orNot", "andNot" and "notEquals" (affects both).
|
||
|
|
* drop the operator "isNotNull" (affects BioCASE).
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.7
|
||
|
|
log
|
||
|
|
@Revision 7
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@a14 1
|
||
|
|
* change maxOccurs of LOPs to unbounded (affects both).
|
||
|
|
d16 3
|
||
|
|
a18 1
|
||
|
|
* Filter enhancements:
|
||
|
|
d21 1
|
||
|
|
d23 1
|
||
|
|
a23 2
|
||
|
|
|
||
|
|
* To be continued...
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.6
|
||
|
|
log
|
||
|
|
@Revision 6
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d24 1
|
||
|
|
a24 1
|
||
|
|
---+++++ Examples
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.5
|
||
|
|
log
|
||
|
|
@Revision 5
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d25 6
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.4
|
||
|
|
log
|
||
|
|
@Revision 4
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d3 1
|
||
|
|
a3 1
|
||
|
|
*General strategy:*
|
||
|
|
d7 1
|
||
|
|
a7 1
|
||
|
|
*Details:*
|
||
|
|
d23 2
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.3
|
||
|
|
log
|
||
|
|
@Revision 3
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d9 12
|
||
|
|
a20 1
|
||
|
|
* To eliminate the DifferencesWithOperators by UsingBiocaseOperators and making the logical operators more readable by not limiting them to being binary.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.2
|
||
|
|
log
|
||
|
|
@Revision 2
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d9 1
|
||
|
|
a9 1
|
||
|
|
* To eliminate the DifferencesInOperators by UsingBiocaseOperators and making the logical operators more readable by not limiting them to being binary.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.1
|
||
|
|
log
|
||
|
|
@Initial revision
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d9 2
|
||
|
|
@
|