XML Schema : AnalysisModule.xsd
Target namespace: http://www.openmicroscopy.org/XMLschemas/AnalysisModule/RC1/AnalysisModule.xsd
Schema Comments:
Imports namespace:http://www.openmicroscopy.org/XMLschemas/CLI/RC1/CLI.xsd schemaLocation: http://www.openmicroscopy.org/XMLschemas/CLI/RC1/CLI.xsd namespace:http://www.openmicroscopy.org/XMLschemas/BinaryFile/RC1/BinaryFile.xsd schemaLocation: http://www.openmicroscopy.org/XMLschemas/BinaryFile/RC1/BinaryFile.xsd namespace:http://www.openmicroscopy.org/XMLschemas/MLI/IR1/MLI.xsd schemaLocation: http://www.openmicroscopy.org/XMLschemas/MLI/IR1/MLI.xsd namespace:http://www.w3.org/XML/1998/namespace schemaLocation: http://www.w3.org/2001/xml.xsd
Processing Instructions
Schema has: 13element definitions,  0 global attribute definitions,  25 element attribute definitions,  1 datatype definitions.
Possible root elements: AnalysisModuleLibrary

Element list

Element AnalysisModule
 
diagram
description Describes an interface to use with a program.
uses elements Declaration, Description, CLI:ExecutionInstructions, MLI:ExecutionInstructions
uses attributes AnalysisModule/Category, AnalysisModule/FeatureIterator, AnalysisModule/ID, AnalysisModule/isStreamAlgorithm, AnalysisModule/ModuleName, AnalysisModule/ModuleType, AnalysisModule/NewFeatureName, AnalysisModule/ProgramID
 
used by elementsAnalysisModuleLibrary
substitution hierarchy AnalysisModule
content sequence
 
Attribute Datatype Use Values Default Comments
isStreamAlgorithm boolean optional (default) false This is a stub for future development. The database location doesn't even exist yet. If the output of the analysis will be the same when pixel positions are scrambled, the analysis is a stream algorithm. Examples of stream algorithms are: A statistics module that produces mean, geometric mean, standard deviation, etc. for pixel intensities. A module to cross correlate pixel intensities across wavelengths. Example of an algorithms that is not a stream algorithm is: FindSpots. (It's a module to find blobs in an image.) If a module is a stream algorithm, it can function across the x, y, z, and time dimensions. Tied to DB. Table PROGRAMS Column IS_STREAM_ALGORITHM
ModuleType {} required pattern:OME::Analysis::.+ As more handlers, are added, this part of the schema needs to be changed Tied to DB. Table PROGRAMS Column MODULE_TYPE
FeatureIterator {} optional (default) If the module iterates over a feature, specify the iterator here. It will reference a feature via the TAG column of the FEATURES table. An example of a module that does not iterate over a feature is Find Cells. It examines one image at a time, hence it iterates over an image, not a feature. It produces zero or more features (Çell) per image. These Cell features belong to an image. This module would not get a FeatureIterator attribute. An example of a module that iterates over a feature is Find Golgi. It examines one CELL at a time. A cell is a feature, hence the module iterates over features, not images or datasets. It produces zero or more Golgi features per Cell feature. These Golgi features belong to a Cell feature. This module would get a FeatureIterator attribute of "CELL". Tied to DB. Table PROGRAMS Column DEFAULT_ITERATOR
NewFeatureName {} optional (default) If this module makes new features, then the new Feature's name needs to be specified here. If the module does not make new features, do not specify a value for this attribute. Tied to DB. PROGRAMS.NEW_FEATURE_TAG
Category {} optional (default) References a Category.
ProgramID string required Eventually will refer to a program. Currently program installation is NOT implemented. So this value is the path to the installed binary file.
ModuleName {} optional (default)
ID AML:ModuleID required
 
source
-<element name="AnalysisModule">
-<annotation>
 <documentation>Describes an interface to use with a program.</documentation>
 </annotation>
-<complexType>
-<sequence>
 <element ref="AML:Description" minOccurs="0" />
 <element ref="AML:Declaration" />
-<choice minOccurs="0">
 <element ref="CLI:ExecutionInstructions" />
 <element ref="MLI:ExecutionInstructions" />
 </choice>
 </sequence>
-<attribute name="isStreamAlgorithm" default="false" type="boolean">
-<annotation>
 <documentation>This is a stub for future development. The database location doesn't even exist yet. If the output of the analysis will be the same when pixel positions are scrambled, the analysis is a stream algorithm. Examples of stream algorithms are: A statistics module that produces mean, geometric mean, standard deviation, etc. for pixel intensities. A module to cross correlate pixel intensities across wavelengths. Example of an algorithms that is not a stream algorithm is: FindSpots. (It's a module to find blobs in an image.) If a module is a stream algorithm, it can function across the x, y, z, and time dimensions. Tied to DB. Table PROGRAMS Column IS_STREAM_ALGORITHM </documentation>
 </annotation>
 </attribute>
-<attribute name="ModuleType" use="required">
-<annotation>
 <documentation>As more handlers, are added, this part of the schema needs to be changed Tied to DB. Table PROGRAMS Column MODULE_TYPE </documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <pattern value="OME::Analysis::.+" />
 </restriction>
 </simpleType>
 </attribute>
-<attribute name="FeatureIterator">
-<annotation>
 <documentation>If the module iterates over a feature, specify the iterator here. It will reference a feature via the TAG column of the FEATURES table. An example of a module that does not iterate over a feature is Find Cells. It examines one image at a time, hence it iterates over an image, not a feature. It produces zero or more features (Çell) per image. These Cell features belong to an image. This module would not get a FeatureIterator attribute. An example of a module that iterates over a feature is Find Golgi. It examines one CELL at a time. A cell is a feature, hence the module iterates over features, not images or datasets. It produces zero or more Golgi features per Cell feature. These Golgi features belong to a Cell feature. This module would get a FeatureIterator attribute of "CELL". Tied to DB. Table PROGRAMS Column DEFAULT_ITERATOR </documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <maxLength value="128" />
 </restriction>
 </simpleType>
 </attribute>
-<attribute name="NewFeatureName">
-<annotation>
 <documentation>If this module makes new features, then the new Feature's name needs to be specified here. If the module does not make new features, do not specify a value for this attribute. Tied to DB. PROGRAMS.NEW_FEATURE_TAG </documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <maxLength value="128" />
 </restriction>
 </simpleType>
 </attribute>
-<attribute name="Category">
-<annotation>
 <documentation>References a Category.</documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <maxLength value="32" />
 </restriction>
 </simpleType>
 </attribute>
-<attribute name="ProgramID" use="required" type="string">
-<annotation>
 <documentation>Eventually will refer to a program. Currently program installation is NOT implemented. So this value is the path to the installed binary file. </documentation>
 </annotation>
 </attribute>
-<attribute name="ModuleName">
-<simpleType>
-<restriction base="string">
 <maxLength value="64" />
 </restriction>
 </simpleType>
 </attribute>
 <attribute name="ID" use="required" type="AML:ModuleID" />
 </complexType>
-<unique name="FormalInput">
 <selector xpath="AML:Declaration/AML:FormalInput" />
 <field xpath="@Name" />
 </unique>
-<unique name="FormalOutput">
 <selector xpath="AML:Declaration/AML:FormalOutput" />
 <field xpath="@Name" />
 </unique>
 </element>

Element AnalysisModuleLibrary
 
diagram
description An analysis module is defined by two things: 1) A program 2) An interface A single program may have multiple interfaces. Why do you need multiple interfaces? Pretend you have a program that calculates simple statistics on the pixels of an image. You can specify which statistics you want via parameters. Typing ./stats -mean -sigma image1 will ouput Image | mean | sigma image1 12.4 1 Typing ./stats -geomean -mean image1 will output Image | geomean | mean image1 12.2 12.4 The outputs are completely different. You need to specify an interface for each of these behaviors. Or pretend you have a powerful program that can do 10 unrelated tasks, each of which outputs an image. While the outputs are the same type and format, they represent 10 completely different things. In this case, it might make sense to define 10 corrosponding AnalysisModule to represent the 10 logical functions. In any case, use AnalysisModule to define an interface and Program to store installation software for a program. This was commented out by Josiah <siah@nih.gov> on July 3, 2003. We don't support Program installation yet, and are using the value of ProgramID in <AnalysisModule> to refer to the location of the installed program. A temporary hack to be sure, but that's the way it works for now. <keyref name = "ProgramRef" refer = "AML:Program"> <selector xpath = "AML:AnalysisModule"/> <field xpath = "@ProgramID"/> </keyref> <unique name = "Program"> <selector xpath = "AML:Program"/> <field xpath = "@ProgramID"/> </unique>
uses elements AnalysisModule, Category, Program
 
content sequence
 
source
-<element name="AnalysisModuleLibrary">
-<annotation>
 <documentation>An analysis module is defined by two things: 1) A program 2) An interface A single program may have multiple interfaces. Why do you need multiple interfaces? Pretend you have a program that calculates simple statistics on the pixels of an image. You can specify which statistics you want via parameters. Typing ./stats -mean -sigma image1 will ouput Image | mean | sigma image1 12.4 1 Typing ./stats -geomean -mean image1 will output Image | geomean | mean image1 12.2 12.4 The outputs are completely different. You need to specify an interface for each of these behaviors. Or pretend you have a powerful program that can do 10 unrelated tasks, each of which outputs an image. While the outputs are the same type and format, they represent 10 completely different things. In this case, it might make sense to define 10 corrosponding AnalysisModule to represent the 10 logical functions. In any case, use AnalysisModule to define an interface and Program to store installation software for a program. </documentation>
 </annotation>
<!-- 
This was commented out by Josiah <siah@nih.gov> on July 3, 2003.
We don't support Program installation yet, and are using the value of ProgramID
in <AnalysisModule> to refer to the location of the installed program. 
A temporary hack to be sure, but that's the way it works for now.
		<keyref name = "ProgramRef" refer = "AML:Program">
			<selector xpath = "AML:AnalysisModule"/>
			<field xpath = "@ProgramID"/>
		</keyref>
		<unique name = "Program">
			<selector xpath = "AML:Program"/>
			<field xpath = "@ProgramID"/>
		</unique>
 -->
-<complexType>
-<sequence>
 <element ref="AML:AnalysisModule" maxOccurs="unbounded" />
 <element ref="AML:Category" minOccurs="0" maxOccurs="unbounded" />
 <element ref="AML:Program" minOccurs="0" maxOccurs="unbounded" />
 </sequence>
 </complexType>
-<unique name="AnalysisModule">
 <selector xpath="AML:AnalysisModule" />
 <field xpath="@AML:ModuleName" />
 </unique>
 </element>

Element Category
 
diagram
description
uses elements Description
uses attributes Category/Path
 
used by elementsAnalysisModuleLibrary
substitution hierarchy Category
content sequence
 
Attribute Datatype Use Values Default Comments
Path {} required pattern:^[A-Za-z0-9 ]+(\.[A-Za-z0-9 ]+)*$ Categories are organized into heirarchical structures. This specifies the full path of this category in the following format. Path = "GrandParent name.Parent name.Category name" If you defined a sub category, we Strongly encourage you to also define all ancestor categories that are not part of the core OME specification.
 
source
-<element name="Category">
-<complexType>
-<sequence>
 <element ref="AML:Description" />
 </sequence>
-<attribute name="Path" use="required">
-<annotation>
 <documentation>Categories are organized into heirarchical structures. This specifies the full path of this category in the following format. Path = "GrandParent name.Parent name.Category name" If you defined a sub category, we Strongly encourage you to also define all ancestor categories that are not part of the core OME specification. </documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <pattern value="^[A-Za-z0-9 ]+(\.[A-Za-z0-9 ]+)*$" />
 </restriction>
 </simpleType>
 </attribute>
 </complexType>
 </element>

Element Declaration
 
diagram
description States module requirements. Formal Inputs are optional because input requirements may be specified by guaranteed image attributes. For example, OME_Image_XYZ_stats requires a path to the OME repository file, and Dimensions. These are given by <RawImageFilePath>, <sizeX>, <sizeY>, <sizeZ>, <sizeT>, and <sizeW>.
uses elements FormalInput, FormalOutput
 
used by elementsAnalysisModule
content sequence
 
source
-<element name="Declaration">
-<annotation>
 <documentation>States module requirements. Formal Inputs are optional because input requirements may be specified by guaranteed image attributes. For example, OME_Image_XYZ_stats requires a path to the OME repository file, and Dimensions. These are given by <RawImageFilePath>, <sizeX>, <sizeY>, <sizeZ>, <sizeT>, and <sizeW>. </documentation>
 </annotation>
-<complexType>
-<sequence>
 <element ref="AML:FormalInput" minOccurs="0" maxOccurs="unbounded" />
 <element ref="AML:FormalOutput" minOccurs="0" maxOccurs="unbounded" />
 </sequence>
 </complexType>
 </element>

Element Description
 
diagram
description Just some free-form text to describe Images, Screens and Projects. The content model is ANY, which means that en entire XML sub-document can be placed here.
 
used by elementsAnalysisModule, Category, FormalInput, FormalOutput, LookupTable
content sequence (default)
type string
 
source
-<element name="Description" type="string">
-<annotation>
 <documentation> Just some free-form text to describe Images, Screens and Projects. The content model is ANY, which means that en entire XML sub-document can be placed here. </documentation>
 </annotation>
 </element>

Element Entry
 
diagram
description
uses attributes Entry/Label, Entry/Value
 
used by elementsLookupTable
substitution hierarchy Entry
content sequence (default)
 
Attribute Datatype Use Values Default Comments
Value {} required Tied to DB. LOOKUP_TABLE_ENTRIES.VALUE
Label {} optional (default) Tied to DB. LOOKUP_TABLE_ENTRIES.LABEL
 
source
-<element name="Entry">
-<complexType>
-<attribute name="Value" use="required">
-<annotation>
 <documentation>Tied to DB. LOOKUP_TABLE_ENTRIES.VALUE</documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <maxLength value="256" />
 </restriction>
 </simpleType>
 </attribute>
-<attribute name="Label">
-<annotation>
 <documentation>Tied to DB. LOOKUP_TABLE_ENTRIES.LABEL</documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <maxLength value="256" />
 </restriction>
 </simpleType>
 </attribute>
 </complexType>
 </element>

Element FormalInput
 
diagram
description Specifies an input requirement for a module. Image dimensions and image file locations (repository or other format) should not be specified with this. Image dimensions are intrisic to an image. They do not represent a special requirement. Image file locations and contents are specified by other elements. Specifically, RawImageFile, RawImageFilePath, XYPlaneFile, and XYPlaneFilePath.
uses elements Description, LookupTable
uses attributes FormalInput/Count, FormalInput/Name, FormalInput/SemanticTypeName, FormalInput/UserDefined
 
used by elementsDeclaration
substitution hierarchy FormalInput
content sequence
 
Attribute Datatype Use Values Default Comments
UserDefined boolean optional (default) false OME interprets this as a recommendation rather than a requirement. Tied to DB. Table FORMAL_INPUTS Column USER_DEFINED
Count {} optional (default) possible values: ! | ? | + | * + Specifies how many counts of this formal input are expected. Meanings are specified below ! = exactly one ? = zero or one + = one or more * = zero or more
Name {} required pattern:[A-Za-z0-9\-\^\(\)_ ]+ Valid characters are alphanumeric and spaces.
SemanticTypeName string required
 
source
-<element name="FormalInput">
-<annotation>
 <documentation>Specifies an input requirement for a module. Image dimensions and image file locations (repository or other format) should not be specified with this. Image dimensions are intrisic to an image. They do not represent a special requirement. Image file locations and contents are specified by other elements. Specifically, RawImageFile, RawImageFilePath, XYPlaneFile, and XYPlaneFilePath. </documentation>
 </annotation>
-<complexType>
-<sequence>
 <element ref="AML:LookupTable" minOccurs="0" />
 <element ref="AML:Description" minOccurs="0" />
 </sequence>
-<attribute name="UserDefined" default="false" type="boolean">
-<annotation>
 <documentation>OME interprets this as a recommendation rather than a requirement. Tied to DB. Table FORMAL_INPUTS Column USER_DEFINED </documentation>
 </annotation>
 </attribute>
-<attribute name="Count" default="+">
-<annotation>
 <documentation>Specifies how many counts of this formal input are expected. Meanings are specified below ! = exactly one ? = zero or one + = one or more * = zero or more </documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <enumeration value="!" />
 <enumeration value="?" />
 <enumeration value="+" />
 <enumeration value="*" />
 </restriction>
 </simpleType>
 </attribute>
-<attribute name="Name" use="required">
-<annotation>
 <documentation>Valid characters are alphanumeric and spaces.</documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <pattern value="[A-Za-z0-9\-\^\(\)_ ]+" />
 </restriction>
 </simpleType>
 </attribute>
 <attribute name="SemanticTypeName" use="required" type="string" />
 </complexType>
 </element>

Element FormalOutput
 
diagram
description Specifies an output element of a module.
uses elements Description
uses attributes FormalOutput/Count, FormalOutput/IBelongTo, FormalOutput/Name, FormalOutput/SemanticTypeName
 
used by elementsDeclaration
substitution hierarchy FormalOutput
content sequence
 
Attribute Datatype Use Values Default Comments
IBelongTo {} optional (default) possible values: [Feature] | [Iterator] Concerning MakeNewFeature attribute of ExecutionInstructions, if a new feature type is made, then there are two possible places a formal output attribute can be stored: It can be stored as an attribute of the FeatureIterator, or it can be stored as an attribute of the new Feature. This tag is supposed to specify which. Can be left blank if module does not make new iterator. Tied to DB. FORMAL_OUTPUTS.FEATURE_TAG Processed before storage to DB
Count {} optional (default) possible values: ! | ? | + | * + Specifies how many counts of this formal output will be produced. Meanings are specified below ! = exactly one ? = zero or one + = one or more * = zero or more
Name {} required pattern:[A-Za-z0-9\-\^\(\)_ ]+
SemanticTypeName string optional (default) THIS IS REQUIRED for every formal output outside of the importer. The importer doesn't know what it will run into before it executes, so it can't declare the semantic type of its outputs. If you are writing a module, I HIGHLY HIGHLY recommend that you type your formal outputs.
 
source
-<element name="FormalOutput">
-<annotation>
 <documentation>Specifies an output element of a module.</documentation>
 </annotation>
-<complexType>
-<sequence>
 <element ref="AML:Description" minOccurs="0" />
 </sequence>
-<attribute name="IBelongTo">
-<annotation>
 <documentation>Concerning MakeNewFeature attribute of ExecutionInstructions, if a new feature type is made, then there are two possible places a formal output attribute can be stored: It can be stored as an attribute of the FeatureIterator, or it can be stored as an attribute of the new Feature. This tag is supposed to specify which. Can be left blank if module does not make new iterator. Tied to DB. FORMAL_OUTPUTS.FEATURE_TAG Processed before storage to DB </documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <enumeration value="[Feature]" />
 <enumeration value="[Iterator]" />
 </restriction>
 </simpleType>
 </attribute>
-<attribute name="Count" default="+">
-<annotation>
 <documentation>Specifies how many counts of this formal output will be produced. Meanings are specified below ! = exactly one ? = zero or one + = one or more * = zero or more </documentation>
 </annotation>
-<simpleType>
-<restriction base="string">
 <enumeration value="!" />
 <enumeration value="?" />
 <enumeration value="+" />
 <enumeration value="*" />
 </restriction>
 </simpleType>
 </attribute>
-<attribute name="Name" use="required">
-<simpleType>
-<restriction base="string">
 <pattern value="[A-Za-z0-9\-\^\(\)_ ]+" />
 </restriction>
 </simpleType>
 </attribute>
-<attribute name="SemanticTypeName" type="string">
-<annotation>
 <documentation>THIS IS REQUIRED for every formal output outside of the importer. The importer doesn't know what it will run into before it executes, so it can't declare the semantic type of its outputs. If you are writing a module, I HIGHLY HIGHLY recommend that you type your formal outputs.</documentation>
 </annotation>
 </attribute>
 </complexType>
 </element>

Element InstallationFile
 
diagram
description Contains a packaged or zipped installation files (binaries or source code).
uses elements Bin:BinaryFile
uses attributes InstallationFile/Format
 
used by elementsProgram
content sequence
 
Attribute Datatype Use Values Default Comments
Format string optional (default) This is a stub for future development. Don't bother with it unless you know more about it. Specifies the packaging and/or compression format of the Installation file.
 
source
-<element name="InstallationFile">
-<annotation>
 <documentation>Contains a packaged or zipped installation files (binaries or source code).</documentation>
 </annotation>
-<complexType>
-<sequence>
 <element ref="Bin:BinaryFile" />
 </sequence>
-<attribute name="Format" type="string">
-<annotation>
 <documentation>This is a stub for future development. Don't bother with it unless you know more about it. Specifies the packaging and/or compression format of the Installation file. </documentation>
 </annotation>
 </attribute>
 </complexType>
 </element>

Element InstallationScript
 
diagram
description The script should interface with the OME API to find all information it needs. (i.e. installation path) It also needs to set the location of the program after the program is installed. The location should be set through the API, but it will propogate to the LOCATION column of the PROGRAMS table.
uses elements Bin:BinaryFile
 
used by elementsProgram
content sequence
 
source
-<element name="InstallationScript">
-<annotation>
 <documentation>The script should interface with the OME API to find all information it needs. (i.e. installation path) It also needs to set the location of the program after the program is installed. The location should be set through the API, but it will propogate to the LOCATION column of the PROGRAMS table.</documentation>
 </annotation>
-<complexType>
-<sequence>
 <element ref="Bin:BinaryFile" />
 </sequence>
 </complexType>
 </element>