476 lines
15 KiB
Plaintext
476 lines
15 KiB
Plaintext
|
head 1.11;
|
||
|
|
access;
|
||
|
|
symbols;
|
||
|
|
locks; strict;
|
||
|
|
comment @# @;
|
||
|
|
|
||
|
|
|
||
|
|
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.11
|
||
|
|
log
|
||
|
|
@Revision 11
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@---+ Search Proposal II
|
||
|
|
|
||
|
|
This proposal for a general search request unifies the FullSearch and the PartialSearch.
|
||
|
|
It defines the search request and response on a RecordBasedApproach as opposed to the DocumentBasedApproach. The provider defines a root table which should be associated to the record elements being served. All conceptual schemas defined by the provider are data structures "rooted" in that record definition.
|
||
|
|
|
||
|
|
---+++++ Request Definition
|
||
|
|
Based on the PartialSearch we suggest this structure for a request (ABCD example):
|
||
|
|
<verbatim>
|
||
|
|
<request>
|
||
|
|
<header>
|
||
|
|
...
|
||
|
|
<type>search</type>
|
||
|
|
</header>
|
||
|
|
<message count="true">
|
||
|
|
<concepts>
|
||
|
|
<concept path="abcd:/unit/Identifications"/> *
|
||
|
|
<concept path="micro:/Strain"/>
|
||
|
|
<concept path="micro:/Temperature"/>
|
||
|
|
</concepts>
|
||
|
|
<filter>
|
||
|
|
...
|
||
|
|
</filter>
|
||
|
|
</message>
|
||
|
|
</request>
|
||
|
|
</verbatim>
|
||
|
|
|
||
|
|
There is no need to give a RecordDefinition as the RecordBasedApproach considers global elements of a ConceptualSchema to represent a single record. If multiple global elements are requested in order to extend a schema (as in the example above), all global elements refer to the same record from a table inside the database, so they should be grouped by the <record> element defined by the protocol.
|
||
|
|
|
||
|
|
|
||
|
|
---+++++ Schema Extension & Response
|
||
|
|
The search is also meant for integrating data in a response from different ConceptualSchemas to support e.g. extension schemas for DarwinCore. The idea is to leave the structure below a root element definition immutable and only allow the addition ("inheritance") of new root elements within a RecordObject.
|
||
|
|
|
||
|
|
So for example a RecordObject of DarwinCore looking like this:
|
||
|
|
<verbatim>
|
||
|
|
<Record xmlns:dwc="http://www.namespaceTBD.org/darwin2">
|
||
|
|
<dwc:DateLastModified>2001-12-17T09:30:47-05:00</DateLastModified>
|
||
|
|
<dwc:InstitutionCode>String</InstitutionCode>
|
||
|
|
<dwc:CollectionCode>String</CollectionCode>
|
||
|
|
<dwc:CatalogNumber>String</CatalogNumber>
|
||
|
|
<dwc:ScientificName>String</ScientificName>
|
||
|
|
<dwc:BasisOfRecord>String</BasisOfRecord>
|
||
|
|
<dwc:Genus>String</Genus>
|
||
|
|
<dwc:Species>String</Species>
|
||
|
|
<dwc:ScientificNameAuthor>String</ScientificNameAuthor>
|
||
|
|
<dwc:Notes>String</Notes>
|
||
|
|
</Record>
|
||
|
|
</verbatim>
|
||
|
|
|
||
|
|
could be extended with microbial data taken from another ConceptualSchema definition like this:
|
||
|
|
<verbatim>
|
||
|
|
<Record xmlns:dwc="http://www.namespaceTBD.org/darwin2" xmlns:micro="http://www.namespaceTBD.org/microbial">
|
||
|
|
<dwc:DateLastModified>2001-12-17T09:30:47-05:00</DateLastModified>
|
||
|
|
<dwc:InstitutionCode>String</InstitutionCode>
|
||
|
|
<dwc:CollectionCode>String</CollectionCode>
|
||
|
|
<dwc:CatalogNumber>String</CatalogNumber>
|
||
|
|
<dwc:ScientificName>String</ScientificName>
|
||
|
|
<dwc:BasisOfRecord>String</BasisOfRecord>
|
||
|
|
<dwc:Genus>String</Genus>
|
||
|
|
<dwc:Species>String</Species>
|
||
|
|
<dwc:ScientificNameAuthor>String</ScientificNameAuthor>
|
||
|
|
<dwc:Notes>String</Notes>
|
||
|
|
<micro:Strain>String</Strain>
|
||
|
|
<micro:Temperature>String</Temperature>
|
||
|
|
</Record>
|
||
|
|
</verbatim>
|
||
|
|
|
||
|
|
Complex data types (objects) like an ABCD unit would be immutable, as the ABCD schema would have to define slots for extending it with other elements. It would only be possible to extend the RecordObject at the same level as the ABCD unit, thus adding RecordObjectProperties.
|
||
|
|
|
||
|
|
Imagine an ABCD unit RecordObject as this:
|
||
|
|
|
||
|
|
<verbatim>
|
||
|
|
<Record xmlns:abcd="http://www.tdwg.org/schemas/abcd/1.46">
|
||
|
|
<abcd:unit>
|
||
|
|
<abcd:SourceInstitutionID>String</abcd:SourceInstitutionID>
|
||
|
|
<abcd:SourceID>normalizedString</abcd:SourceID>
|
||
|
|
<abcd:UnitID>normalizedString</abcd:UnitID>
|
||
|
|
<abcd:LastEditor>normalizedString</abcd:LastEditor>
|
||
|
|
<abcd:DateLastEdited>1967-08-13</abcd:DateLastEdited>
|
||
|
|
<abcd:UnitIPRStatements Language="en-us">
|
||
|
|
<abcd:General>
|
||
|
|
<abcd:ShortText>normalizedString</abcd:ShortText>
|
||
|
|
</abcd:General>
|
||
|
|
</abcd:UnitIPRStatements>
|
||
|
|
<abcd:RecordBasis>Specimen</abcd:RecordBasis>
|
||
|
|
<abcd:Identifications>
|
||
|
|
<abcd:Identification>
|
||
|
|
<abcd:IdentificationResult>
|
||
|
|
<abcd:TaxonIdentified>
|
||
|
|
<abcd:ScientificName>
|
||
|
|
<abcd:FullScientificNameString>normalizedString</abcd:FullScientificNameString>
|
||
|
|
<abcd:NameAtomized>
|
||
|
|
<abcd:Bacterial>
|
||
|
|
<abcd:Genus>String</abcd:Genus>
|
||
|
|
<abcd:Subgenus>String</abcd:Subgenus>
|
||
|
|
<abcd:SubgenusAuthorAndYear>normalizedString</abcd:SubgenusAuthorAndYear>
|
||
|
|
<abcd:SpeciesEpithet>String</abcd:SpeciesEpithet>
|
||
|
|
<abcd:SubspeciesEpithet>String</abcd:SubspeciesEpithet>
|
||
|
|
<abcd:ParentheticalAuthorTeamAndYear>normalizedString</abcd:ParentheticalAuthorTeamAndYear>
|
||
|
|
<abcd:AuthorTeamAndYear>normalizedString</abcd:AuthorTeamAndYear>
|
||
|
|
<abcd:NameApprobation>normalizedString</abcd:NameApprobation>
|
||
|
|
</abcd:Bacterial>
|
||
|
|
</abcd:NameAtomized>
|
||
|
|
</abcd:ScientificName>
|
||
|
|
</abcd:TaxonIdentified>
|
||
|
|
</abcd:IdentificationResult>
|
||
|
|
<abcd:Identifier>
|
||
|
|
<abcd:IdentifierPersonName>
|
||
|
|
<abcd:PersonName>normalizedString</abcd:PersonName>
|
||
|
|
</abcd:IdentifierPersonName>
|
||
|
|
</abcd:Identifier>
|
||
|
|
<abcd:IdentificationDate>
|
||
|
|
<abcd:ISODateTimeBegin>0000-01-01T00:00</abcd:ISODateTimeBegin>
|
||
|
|
</abcd:IdentificationDate>
|
||
|
|
</abcd:Identification>
|
||
|
|
</abcd:Identifications>
|
||
|
|
<abcd:Gathering>
|
||
|
|
<abcd:GatheringDateTime>
|
||
|
|
<abcd:ISODateTimeBegin>0000-01-01T00:00</abcd:ISODateTimeBegin>
|
||
|
|
</abcd:GatheringDateTime>
|
||
|
|
<abcd:GatheringAgents>
|
||
|
|
<abcd:GatheringAgent PrimaryCollectorFlag="1">
|
||
|
|
<abcd:Person>
|
||
|
|
<abcd:PersonName>normalizedString</abcd:PersonName>
|
||
|
|
</abcd:Person>
|
||
|
|
</abcd:GatheringAgent>
|
||
|
|
</abcd:GatheringAgents>
|
||
|
|
</abcd:Gathering>
|
||
|
|
</abcd:unit>
|
||
|
|
</Record>
|
||
|
|
</verbatim>
|
||
|
|
|
||
|
|
Extending this RecordObject with the same concepts as above in DarwinCore, you would get:
|
||
|
|
|
||
|
|
<verbatim>
|
||
|
|
<Record xmlns:abcd="http://www.tdwg.org/schemas/abcd/1.46" xmlns:micro="http://www.namespaceTBD.org/microbial">
|
||
|
|
<abcd:unit>
|
||
|
|
<abcd:SourceInstitutionID>String</abcd:SourceInstitutionID>
|
||
|
|
<abcd:SourceID>normalizedString</abcd:SourceID>
|
||
|
|
<abcd:UnitID>normalizedString</abcd:UnitID>
|
||
|
|
<abcd:LastEditor>normalizedString</abcd:LastEditor>
|
||
|
|
<abcd:DateLastEdited>1967-08-13</abcd:DateLastEdited>
|
||
|
|
<abcd:UnitIPRStatements Language="en-us">
|
||
|
|
<abcd:General>
|
||
|
|
<abcd:ShortText>normalizedString</abcd:ShortText>
|
||
|
|
</abcd:General>
|
||
|
|
</abcd:UnitIPRStatements>
|
||
|
|
<abcd:RecordBasis>Specimen</abcd:RecordBasis>
|
||
|
|
<abcd:Identifications>
|
||
|
|
<abcd:Identification>
|
||
|
|
<abcd:IdentificationResult>
|
||
|
|
<abcd:TaxonIdentified>
|
||
|
|
<abcd:ScientificName>
|
||
|
|
<abcd:FullScientificNameString>normalizedString</abcd:FullScientificNameString>
|
||
|
|
<abcd:NameAtomized>
|
||
|
|
<abcd:Bacterial>
|
||
|
|
<abcd:Genus>String</abcd:Genus>
|
||
|
|
<abcd:Subgenus>String</abcd:Subgenus>
|
||
|
|
<abcd:SubgenusAuthorAndYear>normalizedString</abcd:SubgenusAuthorAndYear>
|
||
|
|
<abcd:SpeciesEpithet>String</abcd:SpeciesEpithet>
|
||
|
|
<abcd:SubspeciesEpithet>String</abcd:SubspeciesEpithet>
|
||
|
|
<abcd:ParentheticalAuthorTeamAndYear>normalizedString</abcd:ParentheticalAuthorTeamAndYear>
|
||
|
|
<abcd:AuthorTeamAndYear>normalizedString</abcd:AuthorTeamAndYear>
|
||
|
|
<abcd:NameApprobation>normalizedString</abcd:NameApprobation>
|
||
|
|
</abcd:Bacterial>
|
||
|
|
</abcd:NameAtomized>
|
||
|
|
</abcd:ScientificName>
|
||
|
|
</abcd:TaxonIdentified>
|
||
|
|
</abcd:IdentificationResult>
|
||
|
|
<abcd:Identifier>
|
||
|
|
<abcd:IdentifierPersonName>
|
||
|
|
<abcd:PersonName>normalizedString</abcd:PersonName>
|
||
|
|
</abcd:IdentifierPersonName>
|
||
|
|
</abcd:Identifier>
|
||
|
|
<abcd:IdentificationDate>
|
||
|
|
<abcd:ISODateTimeBegin>0000-01-01T00:00</abcd:ISODateTimeBegin>
|
||
|
|
</abcd:IdentificationDate>
|
||
|
|
</abcd:Identification>
|
||
|
|
</abcd:Identifications>
|
||
|
|
<abcd:Gathering>
|
||
|
|
<abcd:GatheringDateTime>
|
||
|
|
<abcd:ISODateTimeBegin>0000-01-01T00:00</abcd:ISODateTimeBegin>
|
||
|
|
</abcd:GatheringDateTime>
|
||
|
|
<abcd:GatheringAgents>
|
||
|
|
<abcd:GatheringAgent PrimaryCollectorFlag="1">
|
||
|
|
<abcd:Person>
|
||
|
|
<abcd:PersonName>normalizedString</abcd:PersonName>
|
||
|
|
</abcd:Person>
|
||
|
|
</abcd:GatheringAgent>
|
||
|
|
</abcd:GatheringAgents>
|
||
|
|
</abcd:Gathering>
|
||
|
|
</abcd:unit>
|
||
|
|
<micro:Strain>String</Strain>
|
||
|
|
<micro:Temperature>String</Temperature>
|
||
|
|
</Record>
|
||
|
|
</verbatim>
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.10
|
||
|
|
log
|
||
|
|
@Revision 10
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d67 1
|
||
|
|
a67 1
|
||
|
|
Complex data types (objects) like a ABCD unit would be immutable, as the ABCD schema would have to define slots for extending it with other elements. It would only be possible to extend the RecordObject at the same level as the ABCD unit, thus adding RecordObjectProperties.
|
||
|
|
d69 1
|
||
|
|
a69 1
|
||
|
|
Imagine a ABCD unit RecordObject as this:
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.9
|
||
|
|
log
|
||
|
|
@Revision 9
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d4 1
|
||
|
|
a4 1
|
||
|
|
It defines the search request and response on a RecordBasedApproach as opposed to the DocumentBasedApproach.
|
||
|
|
d27 1
|
||
|
|
a27 1
|
||
|
|
There is no need to give a RecordDefinition as the RecordBasedApproach considers global elements of a ConceptualSchema to represent a single record. If multiple global elements are requested in order to extend a schema (as in the example above), all global elements refering to the same record internally (related inside the database) should be grouped by the protocol defined <record> element.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.8
|
||
|
|
log
|
||
|
|
@Revision 8
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d30 1
|
||
|
|
a30 1
|
||
|
|
---+++++ Schema Extension
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.7
|
||
|
|
log
|
||
|
|
@Revision 7
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d4 1
|
||
|
|
a4 1
|
||
|
|
It defines the search request and response on a RecordBasedApproach as opposed the DocumentBasedApproach.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.6
|
||
|
|
log
|
||
|
|
@Revision 6
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d3 2
|
||
|
|
a4 2
|
||
|
|
This proposal for a general search request substitutes the FullSearch and the PartialSearch.
|
||
|
|
It is also meant for integrating data in a response from different ConceptualSchemas to support e.g. extension schemas for DarwinCore.
|
||
|
|
d6 26
|
||
|
|
a31 1
|
||
|
|
The idea is to leave the structure below a root element definition immutable and only allow the addition ("inheritance") of new root elements within a RecordObject.
|
||
|
|
a196 24
|
||
|
|
|
||
|
|
---+++++ Request Definition
|
||
|
|
Based on the PartialSearch we suggest this structure for a request (ABCD example):
|
||
|
|
<verbatim>
|
||
|
|
<request>
|
||
|
|
<header>
|
||
|
|
...
|
||
|
|
<type>search</type>
|
||
|
|
</header>
|
||
|
|
<message count="true">
|
||
|
|
<recordDefinition path="/unit> *
|
||
|
|
<concepts>
|
||
|
|
<concept path="abcd:/unit/Identifications"/> *
|
||
|
|
<concept path="micro:/Strain"/>
|
||
|
|
<concept path="micro:/Temperature"/>
|
||
|
|
</concepts>
|
||
|
|
<filter>
|
||
|
|
...
|
||
|
|
</filter>
|
||
|
|
</message>
|
||
|
|
</request>
|
||
|
|
</verbatim>
|
||
|
|
|
||
|
|
There is the need to give a RecordDefinition, because when we combine different ConceptualSchemas, the software needs to know what is considered as a record. This can be done by listing a (list) of concepts or even simpler to define a single ConceptualSchema as being the base schema which is defining the record.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.5
|
||
|
|
log
|
||
|
|
@Revision 5
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d194 2
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.4
|
||
|
|
log
|
||
|
|
@Revision 4
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d172 22
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.3
|
||
|
|
log
|
||
|
|
@Revision 3
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d47 1
|
||
|
|
a47 1
|
||
|
|
<Record xmlns:abcd="http://www.tdwg.org/schemas/abcd/1.46" xmlns:micro="http://www.namespaceTBD.org/microbial">
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.2
|
||
|
|
log
|
||
|
|
@Revision 2
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d42 3
|
||
|
|
a44 1
|
||
|
|
Complex data types (objects) like a ABCD unit would be immutable, as the ABCD schema would have to define slots for extending it with other elements. It would only be possible to extend the RecordObject at the same level as the ABCD unit, thus adding RecordObjectProperties. Imagine a simple ABCD unit record:
|
||
|
|
d47 8
|
||
|
|
a54 7
|
||
|
|
<abcd:unit xmlns:abcd="http://www.tdwg.org/schemas/abcd/1.46">
|
||
|
|
<abcd:SourceInstitutionID>String</abcd:SourceInstitutionID>
|
||
|
|
<abcd:SourceID>normalizedString</abcd:SourceID>
|
||
|
|
<abcd:UnitID>normalizedString</abcd:UnitID>
|
||
|
|
<abcd:LastEditor>normalizedString</abcd:LastEditor>
|
||
|
|
<abcd:DateLastEdited>1967-08-13</abcd:DateLastEdited>
|
||
|
|
<abcd:UnitIPRStatements Language="en-us">
|
||
|
|
d56 1
|
||
|
|
a56 1
|
||
|
|
<abcd:ShortText>normalizedString</abcd:ShortText>
|
||
|
|
d58 3
|
||
|
|
a60 3
|
||
|
|
</abcd:UnitIPRStatements>
|
||
|
|
<abcd:RecordBasis>Specimen</abcd:RecordBasis>
|
||
|
|
<abcd:Identifications>
|
||
|
|
d62 27
|
||
|
|
a88 27
|
||
|
|
<abcd:IdentificationResult>
|
||
|
|
<abcd:TaxonIdentified>
|
||
|
|
<abcd:ScientificName>
|
||
|
|
<abcd:FullScientificNameString>normalizedString</abcd:FullScientificNameString>
|
||
|
|
<abcd:NameAtomized>
|
||
|
|
<abcd:Bacterial>
|
||
|
|
<abcd:Genus>String</abcd:Genus>
|
||
|
|
<abcd:Subgenus>String</abcd:Subgenus>
|
||
|
|
<abcd:SubgenusAuthorAndYear>normalizedString</abcd:SubgenusAuthorAndYear>
|
||
|
|
<abcd:SpeciesEpithet>String</abcd:SpeciesEpithet>
|
||
|
|
<abcd:SubspeciesEpithet>String</abcd:SubspeciesEpithet>
|
||
|
|
<abcd:ParentheticalAuthorTeamAndYear>normalizedString</abcd:ParentheticalAuthorTeamAndYear>
|
||
|
|
<abcd:AuthorTeamAndYear>normalizedString</abcd:AuthorTeamAndYear>
|
||
|
|
<abcd:NameApprobation>normalizedString</abcd:NameApprobation>
|
||
|
|
</abcd:Bacterial>
|
||
|
|
</abcd:NameAtomized>
|
||
|
|
</abcd:ScientificName>
|
||
|
|
</abcd:TaxonIdentified>
|
||
|
|
</abcd:IdentificationResult>
|
||
|
|
<abcd:Identifier>
|
||
|
|
<abcd:IdentifierPersonName>
|
||
|
|
<abcd:PersonName>normalizedString</abcd:PersonName>
|
||
|
|
</abcd:IdentifierPersonName>
|
||
|
|
</abcd:Identifier>
|
||
|
|
<abcd:IdentificationDate>
|
||
|
|
<abcd:ISODateTimeBegin>0000-01-01T00:00</abcd:ISODateTimeBegin>
|
||
|
|
</abcd:IdentificationDate>
|
||
|
|
d90 2
|
||
|
|
a91 2
|
||
|
|
</abcd:Identifications>
|
||
|
|
<abcd:Gathering>
|
||
|
|
d93 1
|
||
|
|
a93 1
|
||
|
|
<abcd:ISODateTimeBegin>0000-01-01T00:00</abcd:ISODateTimeBegin>
|
||
|
|
d96 5
|
||
|
|
a100 5
|
||
|
|
<abcd:GatheringAgent PrimaryCollectorFlag="1">
|
||
|
|
<abcd:Person>
|
||
|
|
<abcd:PersonName>normalizedString</abcd:PersonName>
|
||
|
|
</abcd:Person>
|
||
|
|
</abcd:GatheringAgent>
|
||
|
|
d102 3
|
||
|
|
a104 2
|
||
|
|
</abcd:Gathering>
|
||
|
|
</abcd:unit>
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.1
|
||
|
|
log
|
||
|
|
@Initial revision
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d42 1
|
||
|
|
a42 1
|
||
|
|
Complex data types (objects) like a ABCD unit would be immutable, as the ABCD schema would have to define slots for extending it with other elements. It would only be possible to extend the RecordObject at the same level as the ABCD unit. Imagine a simple ABCD unit record:
|
||
|
|
@
|