1 <?xml version="1.0" encoding="UTF-8"?>
6 <!-- 1. Database physical location
7 The database includes an SQL base containing the studies and the document metadata, a Lucene index used for searching studies and
8 knowledges, a file vault including all actual data and a directory where files uploaded and downloaded by users are temporarily saved.
9 All these information are located in sub-directories of a common root directory defined below.
10 This directory must be visible from the server application (Tomcat).
13 <repository disk="D:/users/rkv/SALOME_SIMER/rep" />
21 <!-- 2.1 Project elements identification scheme
22 Studies, Knowledges and Documents are identified by unique user references. The structure of these references is customizable.
23 You customize references through patterns.
24 A reference's pattern is a character string including format directives. These format directives allow you to insert
25 some information into the reference. The following directives are available:
26 - %yy or %yyyy for inserting the entity creation year on 2 or 4 digits
27 - %0000 for inserting a unique index, the number of digits being defined by the number of 0
28 The above index is unique in the scope of cycle defined by the first format directive (year). In other words, this index
29 restarts every new year. As such, for making references unique on this application server, both format directives (cycle
30 and index) must be present in the pattern.
31 Other characters are simply inserted as is in generated references. They can be used for extending the reference uniqueness
32 beyond application servers, by adding a prefix specific to a given server (for example, a company department name).
33 Given that these references may be used as directory or file names of the repository vault, the pattern must not include
34 illicit characters such as '/', '?', '<', '>' etc.
36 <references study="DER%yy%0000"/>
38 <!-- 2.2 Physical files naming scheme
39 The physical data files stored into the repository vault can be named as follows:
40 - By the user-defined title of corresponding documents ("title" name attribute below)
41 - Encoded by a built-in scheme ("encoded" name attribute)
42 - As is, that is, by keeping the name of the imported file ("asis" name attribute - not yet supported)
44 - When using the title scheme, as file names may include accent characters, client browsers must be configured for
45 NOT encoding URLs as UTF-8.
46 - Whatever is the naming scheme used, in order to avoid name clashes, file names are anyway suffixed by an index
47 unique in the scope of the owner study.
49 <files name="encoded"/>
51 <!-- 2.3 Document versions format
52 Defines the format in which version numbers are presented to users.
53 A version number includes a major, a minor and a branch number, when exist.
55 <versions pattern="%M.%m[-%s]"/>
59 <!-- 3. Study step types
60 The user activities involved in studies are defined by study step types. The tag below simply lists all possible steps
61 applicable in a workflow.
62 Step types are defined by type names used in the API for accessing to study activities.
63 The document data produced during these activities are saved into the repository vault. They can be structured in
64 sub-directories of each study root directory. As such, the definition of study step types includes the path of the
65 corresponding sub-directory.
66 The list below does not define the order of steps - this order is specified by the workflow. The steps are listed in
67 an order defining the internal index of steps. These index are used for localizing the activity names and corresponding
71 - "scenario" is a reserved type name.
74 <article type="specification" path="1.Study"/>
75 <article type="design" path="1.Study"/>
76 <article type="modeling" path="2.Geometry"/>
77 <article type="meshing" path="3.Mesh"/>
78 <article type="preprocessing" path="4.Load"/>
79 <article type="solving" path="5.Result"/>
80 <article type="postprocessing" path="6.Analysis"/>
81 <article type="capitalization" path="7.Knowledge"/>
82 <article type="reporting" path="1.Study"/>
86 <!-- 4. Document types
87 All documents under the control of the Study Manager are typed. The tag below simply lists all possible document types
88 involved in a workflow.
89 Document types are defined by type names used in the API for manipulating document types. These type names are also used
90 for localizing document types.
91 The documents have dependencies in accordance to their type. As such, the definition of each document type include the
92 potential dependencies of corresponding documents.
94 Warning: Articles must be ordered in a way that dependent document types (uses attribute values) must previously be defined.
95 Example: "requirements" type must be defined before "specification" because "specification" uses "requirements".
97 - The dependencies are transitive (if document A depends on document B, itself depending on C, A implicitly depends on C).
98 - "knowledge" is a reserved word qualifying Knowledge Elements. So, it must not be used as a document type name.
99 - "default" and "built-in" are also reserved words used for defining validation cycles.
100 - In this version, the "uses" attribute is limited to 1 document type only.
103 <article type="requirements"/>
104 <article type="specification" uses="requirements"/>
105 <article type="design" uses="specification"/>
106 <article type="geometry" uses="design"/>
107 <article type="model" uses="geometry"/>
108 <article type="loads" uses="model"/>
109 <article type="script" uses="loads"/>
110 <article type="log" uses="script"/>
111 <article type="results" uses="script"/>
112 <article type="report" uses="results"/>
113 <article type="memorandum"/>
114 <article type="minutes"/>
118 <!-- 5. Simulation Context types
119 As documents, the simulation contexts are typed. The tag below simply lists the simulation context types available initially,
120 after the installation of the product. These types can then be extended on the fly by end-users when assigning simulation
122 Simulation context types are defined by type names used in the API for manipulating simulation contexts. These type names
123 are also used for localizing simulation contexts types.
125 Warning: The Simulation Context type "product" is mandatory as it is used when creating a study.
129 <!-- General information -->
130 <article type="customer"/>
131 <article type="product"/>
132 <article type="phase"/> <!-- Phase of the product -->
133 <article type="need"/> <!-- Customer needs -->
134 <article type="purpose"/> <!-- Objective of the study -->
135 <article type="physic"/> <!-- Structure analysis, Thermal-hydraulics, Neutronic... -->
137 <!-- Geometry characteristics Examples: -->
138 <article type="object"/> <!-- Car, Plane, Equipment... -->
139 <article type="part"/> <!-- Crankcase, Outer layer... -->
140 <artivle type="geometry"/> <!-- Surface, Volume -->
142 <!-- Model characteristics Examples: -->
143 <article type="model"/> <!-- CSG, FEM... -->
144 <article type="element"/> <!-- Bar, Surface, Volume -->
145 <article type="shape"/> <!-- (Surface) Triangle, Quadrangle... (Volume) Tetrahedron, Hexahedron... -->
146 <article type="order"/> <!-- First-order, Second-order... -->
148 <!-- Analysis type Examples: -->
149 <article type="analysis"/> <!-- Static, Dynamic... -->
151 <!-- Software tools used -->
152 <article type="platform"/>
153 <article type="module"/>
154 <article type="component"/>
158 <!-- 6. Knowledge Elements types
159 As documents and simulation contexts, the knowledges are typed. The tag below lists these knowledge types.
160 Knowledge types are simply defined by type names used in the API for manipulating knowledge types. These type names
161 are also used for localizing knowledge types.
163 Warning: The Knowledge Elements type "usecase" is reserved for internal use.
166 <article type="bestpractice"/>
167 <article type="limitation"/>
168 <article type="inconsistency"/>
169 <article type="metrics"/>
170 <article type="improvement"/>
174 <!-- 7. User activities
177 - Step names must naturally be unique.
178 - Simulation Contexts must be attached to one classification step only.
179 - Result document types must be results of one step only and be part of contents of the corresponding step.
182 <step name="specification">
183 <classification context="customer,product,phase,need,purpose,physic"/>
184 <flow contents="requirements,specification,minutes" result="specification"/>
185 <storage path="1.Study"/>
189 <flow contents="design,memorandum,minutes" result="design"/>
190 <storage path="1.Study"/>
192 <step name="modeling">
193 <classification context="object,part,geometry"/>
194 <flow contents="geometry,memorandum,minutes" result="geometry"/>
195 <storage path="2.Geometry"/>
197 <step name="meshing">
198 <classification context="model,element,shape,order"/>
199 <flow contents="model,memorandum,minutes" result="model"/>
200 <storage path="3.Mesh"/>
202 <step name="preprocessing">
203 <classification context="analysis"/>
204 <flow contents="loads,script,minutes" result="loads"/>
205 <storage path="4.Analysis"/>
207 <step name="solving">
208 <classification context="platform,module,component"/>
209 <flow contents="log,results,minutes" result="results"/>
210 <storage path="5.Result"/>
212 <step name="postprocessing">
213 <flow contents="memorandum,minutes"/>
214 <storage path="6.Report"/>
216 <step name="capitalization">
217 <flow contents="knowledge"/>
218 <storage path="6.Report"/>
221 <step name="reporting">
222 <flow contents="report,minutes" result="report"/>
223 <storage path="1.Study"/>
228 <!-- 8. Document validation cycles
229 Validation cycles define the actors involved in the validation steps of documents. These steps can be
230 "review", "approval" and "acceptance".
232 - Each validation cycle is defined by a tag corresponding to the type of an activity result document.
233 - The actors of validation steps can be
234 "manager", referring the responsible of study,
235 "Nx1", referring the manager of the department (see User definition for more information),
236 "Nx2", referring the boss of the department manager,
237 "customer" (most likely involved in the acceptance step).
240 <specification review="Nx1" approval="Nx2"/>
241 <report review="Nx1" approval="Nx2"/>
242 <default review="manager" />