A project checker for ccpn v3+ projects
Project description
ccpn-project-checker
This is a small utility for checking the basic structure of a ccpn v3 project
Installation
The program maybe installed as a command line tool using pipx:
pipx install ccpn_project_checker
to force the installation to use a particular python distribution use:
pipx install ccpn_project_checker --python <PATH-TO-PYTHON-EXECUTABLE>
where is the path to a python executable e.g. /usr/local/bin/python3
or something
equivalent
Uninstalling
To remove the tool type
pipx uninstall ccpn_project_checker
Invocation
to check a project type:
check-project Sec5Part4.ccpn
this will produce output most of which is a series of notes describing the project, for example the output for the
file Sec5Part4.ccpn
is (note that the output is quite verbose so I have cut out the middle section):
NOTE: target Sec5Part4.ccpn
NOTE: project_name appears to be... Sec5Part4
...
NOTE: analysis took 0.078 seconds
Overall status EXIT_OK [0]: The project was ok
The first thing to not here is that the exit status is OK, this means that the project is ok and is useable as far as the rules the project checker uses to check the contents, note the project could till fail to load because of more subtle errors than the onse checked here.
The possible exit statuses are:
Status name | exit code | Meaning |
---|---|---|
EXIT_OK | 0 | the project is good |
EXIT_ERROR_INCOMPLETE | 1 | the project is bad enough to halt analysis early |
EXIT_ERROR | 2 | project analysis completed but the project has errors |
EXIT_INTERNAL_ERROR | 3 | the run failed and there was an internal error analysis did not complete |
EXIT_WARN | 4 | the project is usable but there are some worry features (e.g. orphaned files etc) |
the exit code is returned to the shell so that it can be used in scripts etc.
echo $?`
0
if we run the checker on a file with errors we again get a set of notes but this is followed by a list of one or more errors
check-project Sec5Part4.ccpn
for example
NOTE: target Broken.ccpn
NOTE: project_name appears to be... Broken
NOTE: the directory Broken.ccpn has the correct suffix
NOTE: analysis took 0.000 seconds
ERRORS [1]:
1. code: MISSING_DIRECTORY
caused by: Broken.ccpn/ccpnv3/memops/Implementation
detailed message: the directory Broken.ccpn/ccpnv3/memops/Implementation doesn't exist
NOTE: the last error [1] prevented a complete analysis of the project
Overall status EXIT_ERROR_INCOMPLETE [1]: There was an error [the last one listed] in the project that prevented complete processing
The cause of this failure is that the directory Broken.ccpn/ccpnv3/memops/Implementation
is missing.
This is a fatal error and the analysis stops at this point.
Testing the installation
the checker also ships with a test suite that can be run using the command:
test-check-project
this will run pytest on the test suite and should produce output similar to that below (note again much of the output has been elided for reasons of space):
=========================================================================== test session starts ============================================================================
platform darwin -- Python 3.10.13, pytest-8.1.1, pluggy-1.4.0 -- /Users/garyt/Library/Application Support/pipx/venvs/ccpn-project-checker/bin/python
cachedir: .pytest_cache
rootdir: /Users/garyt/Library/Application Support/pipx/venvs/ccpn-project-checker/lib/python3.10/site-packages/ccpn_project_checker/tests
plugins: time-machine-2.14.1
collected 58 items
test_api.py::test_memops_checker_read_protected[READ_PROTECTED_PROJECT] PASSED [ 1%]
... [ 98%]
test_cli.py::test_cli_checker PASSED [100%]
====================================================================== 57 passed, 1 skipped in 2.53s =======================================================================
you should see that all the tests pass if they do not then there is a problem with the installation and you should contact the developer on his github issues page. Note you may see a skipped test, in this case this is a test on a set of internal ccpn test projects which are not part of the distribution and so this test is skipped.
Using the project checker as a library
The project checker can also be used as a library, for example to check a project in a python program you can use the following code:
from ccpn_project_checker.DiskModelChecker import ModelChecker
file_path = 'Sec5Part4.ccpn'
checker = ModelChecker()
exit_code = checker.run(file_path)
This gives an exit code and a checker that has errors warning and notes that can be accessed using the errors
warnings
and notes
attributes of the checker object.
The exit_code is an instance of the enumeration DiskModelChecker.ExitStatus which ios defined as follows
from enum import Enum
class ExitStatus(Enum):
EXIT_OK = 0 # the project is good
EXIT_ERROR_INCOMPLETE = 1 # the project is bad enough to halt analysis early
EXIT_ERROR = 2 # the project is bad
EXIT_INTERNAL_ERROR = 3 # the run failed and there was an internal error analysis did not complete
EXIT_WARN = 4 # the project is usable but there are some worry features (orphaned files etc)
these mirror the comand line exit codes listed in the table above.
The messages stored in the checker object are stored as a list of tuples with the first element being the message
and the second being a bool
defining if the message should be indented or not (True indicates the note expects to
be printed without a prefix, False indictates the not expects a prefix such as 'NOTE:').
Warnings and Errors are both stored in a dataclass defined as follows
from dataclasses import dataclass
from ccpn_project_checker.DiskModelChecker import ErrorCode
from typing import Any
@dataclass
class ErrorAndWarningData:
code: ErrorCode
cause: Any
detail: str
is_warning: bool = False
where:
code
is an error code drawn from the enumeration ErrorCode which is defined below
cause
is the object that caused the error, typically a path but i varies depending on error code
detail
is a detailed message about the error
is_warning
is a boolean that is True if the error is a warning and False if it is an error
All warnings maybe treated as errors using the parameter warnings_are_errors
provided to the constructor
of the ModelChecker class; this parameter is False by default.
Error Codes and Meanings
Error code | explanation |
---|---|
MISSING_DIRECTORY | the project directory provide doesn't exist |
IS_NOT_DIRECTORY | a part of the project that should be a directory appears to be something else most probably a file |
IS_NOT_FILE | a part of the project that should be a file is a directory |
NO_MEMOPS_ROOT_FILES | when looking at the project there are no xml files in <PROJECT>.ccpn/ccpnv3/memops/Implementation which should contain the root of the projects storage |
NOT_READABLE | a file or directory in the project is not readable |
READ_PROTECTED_PROJECT | the root project file <PROJECT>.ccpn/ccpnv3/memops/Implementation/<PROJECT.xml> is not readable |
READ_PROTECTED_CCPNV3 | the ccpnv3 directory <PROJECT>.ccpn/ccpnv3> is not readable |
BAD_XML | one of the projects xml files is not correcly formatted xml, the detail will contain a complete diagnosis from the lxml parser. If this occurse on the root project file it is a fatal error otherwise the checker will check as many files as can be read. |
NO_STORAGE_UNIT | each xml file should contains exactly one storage unit with the structure ```xml <_StorageUnit ...></_StorageUnit>. This was missing from the root of the xmnl in the file |
NO_ROOT_OR_TOP_OBJECT | each _StorageUnit should contain exactly one element[^1] no child elements were found it was missing. |
MULTIPLE_ROOT_OR_TOP_OBJECTS_IN_STORAGE_UNIT | each _StorageUnit should contain exactly one element[^1] multiple elements were found. |
ROOT_IS_NOT_TOP_OBJECT | the child of the _StorageUnit in a non root project file was not a descendant of IMPL.TopObject |
ROOT_IS_NOT_MEMOPS_ROOT | the child of the _StorageUnit in the root project file was not of type IMPL.MemopsRoot |
ROOT_HAS_NO_MODEL_VERSION | the _StorageUnit in the root project file shoudl have an attribute release which defines the current version of the dat model being saved. If this is missing or badly formatted its a fatal error as the version of the model being read cannot be ascertained. |
NO_EXO_LINKS_FOUND | the root project file has no exo links [maybe this should be a warning, its not possible for a ccpn project but is otherwise legal] |
EXO_LINK_ELEMENT_SOURCE_MISSING | each exo link has a link-location identified by the guid the exo link encloses, this link location couldsn't be found |
EXO_LINK_ELEMENT_TOO_MANY_SOURCES | each exo link has a link-location identified by the guid the exo link encloses, there should be one link location but more than one was found |
# BASIC_EXO_LINKS_NOT_FOUND | this tested for a basic set of exo links and could be a warning but is unreliable as an error, it is currently disabled |
EXO_LINKED_FILE_MISSING | the exo linked file an exo link's guid points to couldn't be found |
EXO_LINKED_FILE_HAS_WRONG_KEY | an exo link file was found using its guid but the keys in the files key don't maytch those expected |
BADLY_FORMATTED_EXO_LINK_KEY_DATA | the link-location is not correctly formatted and doesn't contain the corrrect elements for its keys |
INTERNAL_AND_EXTERNAL_GUIDS_DISAGREE | the name of an exo linked file contains its instance-guid , it is also present on the top object in the file; the two do not agree. |
MISSING_PACKAGE_GUID | the exo linked file doesn't have the attribute packageGuid in its <_StorageUnit> element which identifies the package it should be stored in. |
UNKNOWN_PACKAGE_GUID | the exo linked files packageGuid attribute in its <_StorageUnit> doesn't idnetify a known package. |
BAD_ROOT_ELEMENT_NAME | the root element in the file doesn't have the correct tag /name which should be of the form <SHORT_PACKAGE_NAME>.<TOP-OBJECT-NAME> |
UNKNOWN_SHORT_PACKAGE_NAME | the root element in the file doesn't have the correct tag /name contains a short package name which isn't known |
SHORT_NAME_GUID_DOESNT_MATCH_PACKAGE_GUID | the root element in the file has a short package name which doesn't match the packageGuid of its <_StorageUnit> |
EXO_FILE_WRONG_STORAGE_LOCATION | the root element in the file has a short package name which doesn't its storage location / package directory in the file system |
MISSING_ATTRIB | only used internally an expected attribute on an xml elemenet is missing |
EXO_FILE_TIME_ATTRIB_MISSING | the <_StorageUnit> in the file doesn't have a time attribute [warning] |
EXO_FILE_TIME_ATTRIB_INVALID | the <_StorageUnit> in the file doesn't have a correctly formatted time attribute it should have the format "%a %b %d %H:%M:%S %Y" [warning] |
EXO_FILE_RELEASE_ATTRIB_MISSING | the <_StorageUnit> in the file doesn't have a release attribute |
EXO_FILE_RELEASE_ATTRIB_INVALID | the <_StorageUnit> in the file doesn't have a correcly formatted release attribute. It should have the form described below in The _StorageUnit Element |
EXO_FILE_RELEASE_DOESNT_MATCH_ROOT | the release version of the model in the <_StorageUnit> doesn't match that of he projects root |
BADLY_FORMATTED_ROOT_EXO_LINK | the exo-link in the file is badly formatted and is not of the form <SHORT-PACKAGE-NAME>.exo-<CLASS=NAME> |
BADLY_FORMATTED_ROLE_EXO_LINK_KEY_DATA | when building a role / reference key the exo-link in the file is badly formatted / missing |
INTERNAL_ERROR | An internal error occured an Exception was raised |
WARNING_DETACHED_FILES | There were top objects in the project that were not referenced by the root file of the project |
BAD_GUID_FORMAT | The GUID had an unexpected format the format of a GUID is described below in GUIDs [warning] This is not an error as long as the name is still globall unique |
NON_CCPN_ASCII_CHARACTER | Characters outside the CCN character set [A-Za-z0-9] + [+_] were found in a filename |
WARNING_EMPTY_CONTAINER | A storage location was foudn that didn't contain a TopObject xml file |
ROOT_FILE_TIME_ATTRIB_MISSING | the <_StorageUnit> in the root file doesn't have a time attribute [warning] |
ROOT_FILE_TIME_ATTRIB_BAD_FORMAT | the <_StorageUnit> in the root file doesn't have a correctly formatted time attribute it should have the format "%a %b %d %H:%M:%S %Y" [warning] |
ROOT_MODEL_VERSION_BAD | the <_StorageUnit> in the root file doesn't have a release attribute |
ROOT_MODEL_VERSION_MISSING | the <_StorageUnit> in the root file doesn't have a correcly formatted release attribute. It should have the form described below in The _StorageUnit Element |
Supporting Utilities
The project checker also ships with a number of supporting utilities that can be used to assist in checking the contents of a project.
MetaModelWalker.py
is a program that can be used to read the metamodel files in a distribution and generate
v_3_1_0_guid_to_storage_location.json
- a dictionary that maps guids to the storage location of the object in the project
v_3_1_0_object_info.json
- a dictionary that maps class-guid
s to instances of ObjectInfo
from dataclasses import dataclass
from typing import List,Dict
@dataclass
class ObjectInfo:
guid: str # the class-guid
name: str # the name of the class
supertype_guids: List[str] # the guids of the supertypes of the class
parent_guid: str # the guid of the parent element [a package]
containment: List[str] # the names of the packages that contain the class
keys: List[str] # the names of the key attributes of the class that uniquely identify and instance in the project
key_type_guids: Dict[str, str] # the guids of the types of the keys
key_model_types: Dict[str, str] # the model types of the keys [either MetaAttribute or MetaRole]
key_defaults: Dict[str, str] # the default values of the keys
an example entry for a MOLE.Molecule
"www.ccpn.ac.uk_Fogh_2006-08-16-14:22:54_00039": {
"guid": "www.ccpn.ac.uk_Fogh_2006-08-16-14:22:54_00039",
"name": "Molecule",
"supertype_guids": [
"www.ccpn.ac.uk_Fogh_2006-09-14-16:28:57_00002"
],
"supertype_names": [
[
"memops",
"Implementation",
"TopObject"
]
],
"parent_guid": "www.ccpn.ac.uk_Fogh_2006-08-16-14:22:54_00038",
"containment": [
"ccp",
"molecule",
"Molecule"
],
"keys": [
"name"
],
"key_type_guids": {
"name": "www.ccpn.ac.uk_Fogh_2006-08-16-14:22:53_00033"
},
"key_model_types": {
"name": "MetaAttribute"
},
"key_types_names": {
"name": [
"memops",
"Implementation",
"Line"
]
},
"key_defaults": {}
},
v_3_1_0_short_name_to_guid.json
a dictionary that maps package short names to guids
MetaModelWalker.py
can be run as a command line tool using the command
scripts/walk-metamodel <MODEL-ROOT-DIRECTORY> <MODEL-VERSION>
by default is the current directory and is v_3_1_0
it is assumed that the model shoud be read from the directory <MODEL-ROOT-DIRECTORY> "ccpnmodel" / "versions" / <MODEL-VERSION>
MetaModelWalker.py
can also be used as a library by importing the MetaModelWalker
class and using the build_top_info
method
CCPN Project Structure
[!Note] we will use the project Sec5Par4.ccpn as an example throughout this section
A ccpn v3 project [hence forrward a v3 project] is stored in a directory hierarchy with a specific structure containing
a series of XML files. The name of the top level directory is <PROJECT-NAME>.ccpn
where <PROJECT-NAME>
is the name of the project,
the .ccp
n suffix is not required even for ccpn v3 project but is added by ccpn programs for the convenience of the user.
Packages
All data in a v3 project is stored in packages, a package is a collection of data that is stored in files in a
structured hierarchy of directories in much the same way that python modules are saved in packages. The package hierarchy of the Sec5Part4.ccpn
project is shown below as a tree.
.
├── ccp
│ ├── general
│ │ └── DataLocation
│ │ └── standard+default_user_2022-02-23-14-57-20-615_00001.xml
│ ├── lims
│ │ ├── RefSampleComponent
│ │ │ └── default+default_user_2022-02-23-14-57-20-616_00003.xml
│ │ └── Sample
│ │ └── default+default_user_2022-02-23-14-57-20-616_00002.xml
│ ├── molecule
│ │ ├── MolSystem
│ │ │ └── default+default_user_2022-02-23-14-57-20-617_00001.xml
│ │ └── Molecule
│ │ └── Sec5+Sec5Part1_user_2022-02-23-15-20-24-415_00001.xml
│ └── nmr
│ └── Nmr
│ └── default+default_user_2022-02-23-14-57-20-616_00001.xml
├── ccpnmr
│ └── gui
│ ├── Task
│ │ └── user+View+default_user_2022-02-23-14-57-20-617_00003.xml
│ └── Window
│ └── _ccp_nmr_Nmr_NmrProject___default___+default_user_2022-02-23-14-57-20-617_00002.xml
└── memops
└── Implementation
└── Sec5Part4.xml
The tree can be divided into two parts a root package memops/Implementation
and a series of exolinked packages such as ccp/general
and ccpnmr/gui
.
Note that the file stored in the root package has a plane text name which is usually the same as the name of the project,
in this case Sec5Part4.xml
. The files stored in the exo linked packages have names that are a mixture of guids
and keys
[vide infra] and are stored in the rest of the tree [the exo linked package tree]. An example of an exo linked file and package would be
Sec5+Sec5Part1_user_2022-02-23-15-20-24-415_00001.xml
which defines a molecul and is stored in the package molecule/Molecule
.
All files in the tree are xml files, in older versions of the ccpn data model backup files of the <FILE-NAME>.xml.bak
were also stored
alongside the main files, but this is no longer the case, instead there are archive
and backup
directories containing complete saved and readable models at the same
place in the hierarch as the ccpnv3 directory.
Packages can have two names a short two letter name such as IMPL
which is equivalent to the second longer name memops/Implementation
.
All packages and all typed elements in the project / model are also identified by a globally unique identifier or GUID
such as www.ccpn.ac.uk_Fogh_2006-08-16-14:22:53_00025
these values are date and serial number based and are unique to a
particlular element in a project or model and should not repeat anywhere e ver excapt for the same elemement (i.e. across the universe!).
Note short and long names are not mixed, gerenally short names are used inside XML files as element tags and long names are used to name directory hierarchies.
The structure of a GUID
is described elsewhere, see the section GUIDs
GUIDs
Globally unique identifiers or GUIDs are used to identify all elements in a ccpn project. A GUID is a string of the form
www.ccpn.ac.uk_Fogh_2006-08-16-14:22:53_00025
where the first part is the domain of the element (www.ccpn.ac.uk_Fogh), the second part is the date
the element was created (2006-08-16-14:22:53) and the third part is a serial number (00025). The parts are separated by underscores.
The form of the domain varies dependinmg on the form of the GUID.
The CCPN data model uses two forms of GUID those defining classes in the model and those defining instances of classes in the model.
We shall call these class guids
and instance guids
respectively.
The first form the class-guid
is usually of the form www.ccpn.ac.uk_Fogh_2006-08-16-14:22:53_00025
the second form is used to define instances of classes in the model and is of the form default_user_2022-02-23-14-57-20-617_00003
All class guids can be found in the files model_info/v_3-1_0_short_name_to_guid.json
model_info/v_3_1_0_object_info.json
and model_info/v_3-1_0_guid_to_storage_location.json
The Root Package and its Contents
The reading of project starts at the root XML file which is stored in the directory
<PROJECT-NAME>.ccpn/ccpnv3/memops/Implementation
generally in a file called
<PROJECT-NAME>.ccpn/ccpnv3/memops/Implementation/<PROJECT-NAME>.xml
. However, the exact name of the root file is not
required to match the PROJECT-NAME, but it must have the .xml suffix and be the only xml file in the ccpnv3/memops/Implementation
directory. The roots file contains information about the root storage element of the project,
in the case of a ccpn NMR project this is an element with the tag IMPL.MemopsRoot
. All other componenets of the
project
are then stored in a series of XML files in the other directories in the project and will be referenced by exo links
from
the project root file [vide infra].
The _StorageUnit Element
All v3 project files (both root and exo files) have a consistent structure they are XML files, and so they start with an
XML declaration
<?xml version="1.0" encoding="UTF-8"?>
. they then always have a contain a storage element of the form
<_StorageUnit ...> ... </_StorageUnit>
which is the root elemenet of the XML file. There can only be a single storage
elemement in the file. The <_StorageUnit> has a number of attributes which are common across all v3 files, these are
time
the time the file was stored, the format of this attribute is "%a %b %d %H:%M:%S %Y" e.g. Tue May 10 12:29:35
2022"
release
the version of the data model used to store the project. This is a triplet of the form ..
and must be integers but patch can also have a prefix letter which is usally a or b to indicate an
alpha or beta version e.g 3.1.0
packageGuid
is a guid indicating which package the file should be stored in for example
www.ccpn.ac.uk_Fogh_2006-08-16-14:22:53_00025 which defines the implimentation package. A list of guids and package
short names is included in the ccpn_project-checker in the file model_info/v_3-1_0_short_name_to_guid.json
the storage location of the package defined by the guid can be found in the file
model_info/v_3_1_0_guid_to_storage_location.json
originator
defines which program wrote the file and is usually CCPN Python XmlIO
nota bene only the time
and guid
attributes are required for reading of the model.
The Root element of the Root File
The root elemenet of the root file is a IMPL.MemopsRoot
element. The only important atribute of this element is the
name
element which is the original name the file was saved under, it can vary from the name of the root xml file and
the name of the project directory, the current name of the project is always the name of the project directory.
Acceptable Characters in CCPN file names
Because of the way ccpn keys and guids are stored the only accaptable characters in a ccpn project and other files name are those that are
in the set a-zA-Z0-9
. Some additional characters are also allowed in the project name specifically the . character in the .ccpn prefix.
Files outside the project root file are allowed some extra characters, specifically _ is used to escape spaces and as part of guids
and the + character is used in exo linked files but these are not allowed in the Root Files name (or maybe they are, check?)
Exo Links
The root file contains a series of exo-links
which are links to objects in other files in the project [exo linked files]. These links are stored in the
file as two parts. The first is a series of elements of the form <MOLE.exo-Molecule>
which defines an exo link and we shall call an exo-link
. In this
case the rexo-link
link is to a molecule [Molecule
] stored in the MOLE package. These exo-link
only occur once in the file and they point to a TopObject which is stored in an exo linked file.
The second part of the exo link which we shall call the linked-location
are stored elsewhere in file and are identified by a guid
attribute which contains an instance-guid
.
The instance-guid
is stored in the exo-link
element in an IMPL.GuidString
object (in this case Sec5Part1_user_2022-02-23-15-20-24-415_00001
) as shown below:
<IMPL.MemopsRoot.currentMolecule>
<MOLE.exo-Molecule>
<IMPL.GuidString>Sec5Part1_user_2022-02-23-15-20-24-415_00001</IMPL.GuidString>
</MOLE.exo-Molecule>
<I/MPL.MemopsRoot.currentMolecule>
The instance-guid
can then be used to
- find the file that the exo link points to
- Find the exo link element in the project root file that the exo link points to
Lets first follow the instance-guid
to the file that the exo link points to. The file that the exo link points to is
identified by a package name guid and a key. The package name is stored as a short package name MOLE in the exo elements tag which defines the
package ccp/molecule/Molecule
[class-guid
www.ccpn.ac.uk_Fogh_2006-08-16-14:22:54_00038]. This then defines the directory the exo linked top object is saved in. The instance-guid
which is the guid leading to the exo linked file and appears in the name of the exo linked file
is Sec5Part1_user_2022-02-23-15-20-24-415_00001
and this identifies a file in its package directory ccp/molecule/Molecule
. The name of this file
is Sec5+Sec5Part1_user_2022-02-23-15-20-24-415_00001.xml
it consists of the top objects keys separated by +
s '. In this case the key is the name of the Molecule
which is Sec5
the key is then followed by a +
and the instance-guid
of the object Sec5Part1_user_2022-02-23-15-20-24-415_00001
followed by the suffix .xml
.
More details of the exo linked files filename and escaping key and reference based keys are given below in the section The TopObject Element Key
Note that exolinked top objects can be stored in the project but can also refer to reference top objects which are not stored in the project directory,
these top object files are listed in the file model-info/data_file_names.txt
Now lets see where else this instance-guid
appears in the root file. If we scan the root file we can find an element which has a
guid
attribute. In this case this is the element
<IMPL.MemopsRoot.molecules>
<MOLE.Molecule _ID="1" _lastId="755" createdBy="user" guid="Sec5Part1_user_2022-02-23-15-20-24-415_00001" isFinalised="true">
<MOLE.Molecule.name>
<IMPL.Line>Sec5</IMPL.Line>
</MOLE.Molecule.name>
</MOLE.Molecule>
</IMPL.MemopsRoot.molecules>
This element is the MOLE.Molecule
element that the exo link points to and is unique within the file . Other references
to it within the root file will be via it _ID attribute [check] which is a unique identifier for the element within a file.
The TopObject Element Key
Each exo linked element as well as having an instance-guid
also has a key which is a series of values which are unique
within the project. The key is stored in the link location as children which are identified by the metamodel. If we look at the
file model-info/v_3_1_0_object_info.json
we can find the information derived from the metamodel file [****] that defines a
molecules key. In this case the key is the name
of the object which is Sec5
and is stored in the MOLE.Molecule.name
element as
as an IMPL.Line
.
<IMPL.MemopsRoot.molecules>
<MOLE.Molecule _ID="1" _lastId="755" createdBy="user" guid="Sec5Part1_user_2022-02-23-15-20-24-415_00001" isFinalised="true">
<MOLE.Molecule.name>
<IMPL.Line>Sec5</IMPL.Line>
</MOLE.Molecule.name>
</MOLE.Molecule>
</IMPL.MemopsRoot.molecules>
If we look at the file name we can see that the key is stored in the file name as Sec5+Sec5Part1_user_2022-02-23-15-20-24-415_00001.xml
where the key is Sec5
and the guid is Sec5Part1_user_2022-02-23-15-20-24-415_00001
.
If there are multiple keys they appear in the filename separated by a +
character, any spaces in the key are escaped as the _
character.
Keys appear in the filename in the order they appear in the metamodel file, some keys may be missed out in which case they
are replaced by the default value which is stored in the metamodel file. An example of this is *** [does this introducte ambiguity???].
Finaly while this key is an atttribute keys it can also be links to other objects in the project. In this case the key is built from
the type of the linked object and its keys. An example of this is ... Note keys are also saved in the exo linked object in the exo linked filed as well.
The TopObject Element File
Top objects are stored in files in the project in the same way as the root file. The structure of the file is the same as the
root file with a _StorageUnit
element at the root of the file. The file is stored in a directory defined by the package name.
The file name is defined by the key and the guid of the top object. The key is stored in the exo linked file as values of the
object in the same ways as it is stored in the root object.
[^1]: this elemenet should be a descendant of IMPL.MemopsRoot
if the file is the root project file or otherwise a
descendant of IMPL.TopObject
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
File details
Details for the file ccpn_project_checker-0.1.17.tar.gz
.
File metadata
- Download URL: ccpn_project_checker-0.1.17.tar.gz
- Upload date:
- Size: 1.0 MB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/4.0.2 CPython/3.12.2
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | 15e28c4ce24972e4b76e65f1a754ae37b01feb99cc0add8b5215e4cf11a5ff57 |
|
MD5 | 9cc0ee3d3e586e4dd2fbbe65ece53b58 |
|
BLAKE2b-256 | e11a7cee806006baa71ad94d658960100c9d69bb206b25fcfb9968fb2ef0c8e5 |
File details
Details for the file ccpn_project_checker-0.1.17-py3-none-any.whl
.
File metadata
- Download URL: ccpn_project_checker-0.1.17-py3-none-any.whl
- Upload date:
- Size: 1.3 MB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/4.0.2 CPython/3.12.2
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | 2d1e265f415e9015b6baabf9d6cb95d6cdac86cff559146fce72fc2cc63031b9 |
|
MD5 | 39de2f11fd309aab27f0ecd7063b8bd6 |
|
BLAKE2b-256 | 532189f2a368e4dc8e454efb65869fa361375821ec83642e0848a7d3f30399e0 |