98 lines
5.3 KiB
Plaintext
98 lines
5.3 KiB
Plaintext
head 1.4;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.4
|
|
date 2009.11.25.03.14.39; author GarryJolleyRogers; state Exp;
|
|
branches;
|
|
next 1.3;
|
|
|
|
1.3
|
|
date 2009.11.20.02.45.32; author LeeBelbin; state Exp;
|
|
branches;
|
|
next 1.2;
|
|
|
|
1.2
|
|
date 2007.03.06.17.30.00; author TWikiGuest; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2005.01.06.16.48.38; author BobMorris; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.4
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%META:TOPICINFO{author="GarryJolleyRogers" date="1259118879" format="1.1" version="1.4"}%
|
|
%META:TOPICPARENT{name="ToolsForBDI.SDD"}%
|
|
---+!! %TOPIC%
|
|
|
|
|
|
This is not an existing tool, but something I was discussing with Bryan Heidorn and which I think could very easily be developed to assist us with testing the scalability of the BDI.SDD_ schema and the capabilities of any BDI.SDD_ software we develop.
|
|
|
|
One of the challenges in the BDI.SDD_ schema is the number of Key/KeyRef pairs which need to be handled, along with all of the associated constraint processing. We need to get a better feel for the performance implications of these characteristics. Fortunately it seems likely that these factors are largely independent of the actual meaning of any particular Terminology, Entities or Descriptions elements. We could therefore create a program to generate BDI.SDD_ test documents varying a small number of parameters. The parameters could be something like: <nop>NumberOfCharacters, <nop>NumberOfStatesPerCharacter, <nop>NumberOfClassDescriptions, <nop>NumberOfObjectDescriptions, etc. We could vary the parameters to alter the depth of the class hierarchy and the number of specimens per taxon and the complexity of the terminology (along with whether or not it is imported/included). The actual elements could be little more than "State 1006", "Description 214", etc., although we could vary the balance of <nop>NaturalLanguageDescriptions and <nop>CodedDescriptions. I think this could be a very simple program but could give us a wide variety of different documents against which to test BDI.SDD_ processors.
|
|
|
|
-- Main.DonaldHobern - 21 May 2004@
|
|
|
|
|
|
1.3
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="LeeBelbin" date="1258685132" format="1.1" reprev="1.3" version="1.3"}%
|
|
d6 1
|
|
a6 1
|
|
This is not an existing tool, but something I was discussing with Bryan Heidorn and which I think could very easily be developed to assist us with testing the scalability of the BDI.SDD schema and the capabilities of any BDI.SDD software we develop.
|
|
d8 1
|
|
a8 1
|
|
One of the challenges in the BDI.SDD schema is the number of Key/KeyRef pairs which need to be handled, along with all of the associated constraint processing. We need to get a better feel for the performance implications of these characteristics. Fortunately it seems likely that these factors are largely independent of the actual meaning of any particular Terminology, Entities or Descriptions elements. We could therefore create a program to generate BDI.SDD test documents varying a small number of parameters. The parameters could be something like: <nop>NumberOfCharacters, <nop>NumberOfStatesPerCharacter, <nop>NumberOfClassDescriptions, <nop>NumberOfObjectDescriptions, etc. We could vary the parameters to alter the depth of the class hierarchy and the number of specimens per taxon and the complexity of the terminology (along with whether or not it is imported/included). The actual elements could be little more than "State 1006", "Description 214", etc., although we could vary the balance of <nop>NaturalLanguageDescriptions and <nop>CodedDescriptions. I think this could be a very simple program but could give us a wide variety of different documents against which to test BDI.SDD processors.
|
|
d10 1
|
|
a10 1
|
|
-- Main.DonaldHobern - 21 May 2004
|
|
@
|
|
|
|
|
|
1.2
|
|
log
|
|
@Added topic name via script
|
|
@
|
|
text
|
|
@d1 2
|
|
a4 2
|
|
%META:TOPICINFO{author="BobMorris" date="1105030118" format="1.0" version="1.1"}%
|
|
%META:TOPICPARENT{name="ToolsForSDD"}%
|
|
d6 1
|
|
a6 1
|
|
This is not an existing tool, but something I was discussing with Bryan Heidorn and which I think could very easily be developed to assist us with testing the scalability of the SDD schema and the capabilities of any SDD software we develop.
|
|
d8 1
|
|
a8 1
|
|
One of the challenges in the SDD schema is the number of Key/KeyRef pairs which need to be handled, along with all of the associated constraint processing. We need to get a better feel for the performance implications of these characteristics. Fortunately it seems likely that these factors are largely independent of the actual meaning of any particular Terminology, Entities or Descriptions elements. We could therefore create a program to generate SDD test documents varying a small number of parameters. The parameters could be something like: <nop>NumberOfCharacters, <nop>NumberOfStatesPerCharacter, <nop>NumberOfClassDescriptions, <nop>NumberOfObjectDescriptions, etc. We could vary the parameters to alter the depth of the class hierarchy and the number of specimens per taxon and the complexity of the terminology (along with whether or not it is imported/included). The actual elements could be little more than "State 1006", "Description 214", etc., although we could vary the balance of <nop>NaturalLanguageDescriptions and <nop>CodedDescriptions. I think this could be a very simple program but could give us a wide variety of different documents against which to test SDD processors.
|
|
a10 1
|
|
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 2
|
|
@
|