-
Notifications
You must be signed in to change notification settings - Fork 13
/
get-response.xsd
645 lines (593 loc) · 38.8 KB
/
get-response.xsd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:c="https://github.com/erasmus-without-paper/ewp-specs-types-contact/tree/stable-v1"
xmlns:ewp="https://github.com/erasmus-without-paper/ewp-specs-architecture/blob/stable-v1/common-types.xsd"
xmlns:trm="https://github.com/erasmus-without-paper/ewp-specs-types-academic-term/tree/stable-v1"
elementFormDefault="qualified"
targetNamespace="https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v6/endpoints/get-response.xsd"
xmlns="https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v6/endpoints/get-response.xsd"
>
<xs:import
schemaLocation="https://raw.githubusercontent.com/erasmus-without-paper/ewp-specs-architecture/stable-v1/common-types.xsd"
namespace="https://github.com/erasmus-without-paper/ewp-specs-architecture/blob/stable-v1/common-types.xsd"
/>
<xs:import
schemaLocation="https://raw.githubusercontent.com/erasmus-without-paper/ewp-specs-types-contact/stable-v1/schema.xsd"
namespace="https://github.com/erasmus-without-paper/ewp-specs-types-contact/tree/stable-v1"
/>
<xs:import
schemaLocation="https://raw.githubusercontent.com/erasmus-without-paper/ewp-specs-types-academic-term/stable-v1/schema.xsd"
namespace="https://github.com/erasmus-without-paper/ewp-specs-types-academic-term/tree/stable-v1"
/>
<xs:annotation>
<xs:documentation>
This schema is a part of the Erasmus Without Paper project. Before you start
using it, make sure you have read the general rules described here:
http://developers.erasmuswithoutpaper.eu/
</xs:documentation>
</xs:annotation>
<xs:element name="iias-get-response">
<xs:annotation>
<xs:documentation>
This describes the format of the response returned by the `get` endpoint of
EWP Interinstitutional Agreements API.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="iia" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
This represents a single IIA. Servers will produce one such element for
each of the `iia_id` or `iia_code` values passed in the Institutions API
call.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="partner" minOccurs="2" maxOccurs="2">
<xs:annotation>
<xs:documentation>
A list of HEIs participating in this IIA.
This list includes the local HEI which MUST be the first element on this list.
In other words:
* The value of `hei-id` of the first `partner` MUST match the value passed in
the `hei_id` request parameter,
* Both `iia-id` and `iia-code` elements MUST be present in the first `partner`
element (even though it's not required by the schema itself), and one of them
MUST match one of the values passed in the `iia_id` or `iia_code` request
parameter.
* The server will usually fill much more data for the first `partner`.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="hei-id" type="xs:string" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
The ID of the partner HEI.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ounit-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Optional organizational unit surrogate ID. If given, then it refers to the unit
within the partner HEI's organizational structure, which is the actual partner
of this agreement. Agreements can be signed between units, not only between
HEIs: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/11
If provided, then it MUST have the value of the "official" ounit-id, exactly as
it has been assigned by the *partner HEI* in its Organizational Units API. If
this official ID is not known by the server (and it often isn't), then this
element MUST be skipped. This is a surrogate ID, so it SHOULD NOT be displayed
to the user (use `ounit-code` for that).
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="iia-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
The partner's unique surrogate ID of this IIA. This is a surrogate ID, so it
SHOULD NOT be displayed to the user (use `iia-code` for that).
Since IIA IDs are local (unique within a single HEI, but not within the world),
each partner is allowed to have his own ID for the same IIA. If this server is
aware of the IDs used by the other partners, then it MUST output it here
(otherwise, a copy of the agreement in our system could be treated
as a separate different agreement in partner's system).
Server implementers MUST use immutable surrogate keys for their work with EWP.
https://github.com/erasmus-without-paper/ewp-specs-architecture#ids
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="iia-code" type="xs:string" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
The partner's "human readable" ID of this IIA (aka an agreement number). If
this server is aware of the agreement numbers used by the other partners, then
it SHOULD output it here.
Since `iia-id` values should contain surrogate identifiers (and, as such,
should not be displayed to the user), we require additional "human readable"
agreement codes/numbers to be provided here. These codes SHOULD be displayed to
the user, and they MAY be used for searching, but they are *not used* to
directly identify entities in EWP network.
Related links:
https://github.com/erasmus-without-paper/ewp-specs-architecture#ids
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="signing-contact" type="c:Contact" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
This describes that person who acts as the partner's institutional coordinator
for this IIA (if known).
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="signing-date" type="xs:date" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
The date when the agreement has been first signed by the *partner's*
institutional coordinator (if known).
Note, that agreements are often modified *after* they were signed. These
modifications don't usually require official signatures, though. This date
refers to the "first signing" only.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element ref="c:contact" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of other partner contacts related to this IIA (or to mobilities related
to this IIA).
Only some servers provide these, even for the *local* partner. Many HEIs
(especially the smaller ones) don't granulate their contacts in such a detailed
way. Instead, they have a fixed set of contacts described in their Institutions
API.
These contacts take precedence over contacts defined in the Institutions API
and Organization Units API for the partner HEI/unit. Clients are advised to
display these contacts in a separate section above other contacts - so that the
users will notice them first (before scrolling down to other, more generic
contacts).
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="in-effect" minOccurs="1" maxOccurs="1" type="xs:boolean">
<xs:annotation>
<xs:documentation>
Boolean. True, if this IIA *is* or *once was* in effect - that is, it has been
signed, and the partners are (or were) following its rules. False, if this IIA
is a draft or proposal only (and it hasn't been agreed on).
This flag allows to differentiate between actual agreements, and the *proposed*
agreements. (IIAs API allows to peek on both.)
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="cooperation-conditions" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
List of all cooperation conditions defined in this agreement.
If you are sending conditions-hash, be consistent in ordering cooperation conditions.
The hash SHOULD NOT change if the cooperation conditions are not really changing.
An exception to this are the `sending-contact` and `receiving-contact` subelements
that are not taken into account when calculating hash.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="student-studies-mobility-spec" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of descriptions of student mobilities *for studies* (not to be
confused with student mobility *for traineeships*).
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element ref="student-traineeship-mobility-spec" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of descriptions of student mobility *for traineeships*.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element ref="staff-teacher-mobility-spec" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of descriptions of staff mobility *for teaching*.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element ref="staff-training-mobility-spec" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of descriptions of staff mobility *for training*.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="conditions-hash" type="ewp:Sha256Hex" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
The SHA-256 digest of the cooperation-conditions element but *excluding*
`sending-contact` and `receiving-contact` subelements. Before
calculating the hash, the cooperation-conditions element should be normalized
using Exclusive XML Canonicalization.
This element is not required. However, if it is not present, your partner
will not be able to approve your version of the agreement using EWP IIAs Approval API.
If you want to get approval of your agreements, then you should always send
the conditions hash.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="pdf" type="xs:base64Binary" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
PDF version of the agreement. SHOULD be skipped if the `send_pdf` request parameter
value is `false`.
Notes for client implementers:
The pdf element can be missing even if the `send_pdf` parameter was set to true.
Some servers MAY not support PDFs at all or the PDF version can be not ready yet.
For security reasons, you may consider checking the content type of the file
before displaying it in the browser.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="MobilitySpecification" abstract="true">
<xs:annotation>
<xs:documentation>
A common parent class for all mobility specifications.
Note that "mobility specification" is a name we (EWP designers) made up. We
needed to have a descriptive name for this particular entity, and we couldn't
find such name in existing Erasmus+ templates. In other words, this is an
EWP-specific term only, and you should probably avoid using it in other
contexts.
Mobility specification may also be considered as a subclass of "cooperation
condition", but - since currently all nonabstract subclasses inherit from
MobilitySpecification - no CooperationCondition class is introduced. See here:
https://github.com/erasmus-without-paper/ewp-wp3-data-model/issues/10
Each specification has a sending and receiving partner. Each specification
represents an agreement that, for each of the academic years listed within, the
sending partner will send a particular number of people to the receiving
partner, for a particular average duration each (e.g. for 8 weeks). This
describes an unidirectional flow - if people are sent in both directions, two
separate mobility specifications need to be defined (one for each direction).
More requirements (e.g. *who* is being sent to do *what*) are defined in
specific `*-mobility-spec` subclasses.
This type, nor any of its subclasses, SHOULD NOT be referenced outside of the
EWP IIAs API. It is likely to be modified, or to be removed, in the future.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="sending-hei-id" type="xs:string" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
SCHAC ID of the sending HEI. Must match the `hei-id` of one of the IIA partners.
https://github.com/erasmus-without-paper/ewp-specs-api-registry/#schac-identifiers
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="sending-ounit-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Optional ID of the sending organizational unit.
This data might be relevant for some partners, while other partners might
ignore it completely. If the server is aware that particular students should
come from a particular organizational unit, then it reports it here. Note, that
this MAY be the "root" unit (the one representing the entire HEI).
This ID is defined by the HEI referred to in the `sending-hei-id` element.
If the server is not aware of this ID, then it won't provide it. Clients
can retrieve further information on this unit via Organizational Units API, but
note, that it is not obvious *which* Organizational Units API the client should
use. See similar notes on `iia/partner-hei/hei-id` element. Discuss here:
https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/6
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="sending-contact" type="c:Contact" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of contacts on the sending HEI's side, related to the mobilities based
on this specification.
Not all servers provide these! Many HEIs (especially the smaller ones) don't
granulate their contacts in such a detailed way. Instead, they have a fixed set
of contacts described in their Institutions API.
These contacts take precedence over contacts defined in the Institutions API,
and the ones defined in the `contact` elements of *this* API (outside of the
cooperation conditions list). Clients are advised to display these contacts in
a separate section above other contacts - so that the users will notice them
first (before scrolling down to other, more generic contacts).
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="receiving-hei-id" type="xs:string" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
SCHAC ID of the receiving HEI. Must match the `hei-id` of one of the IIA partners.
https://github.com/erasmus-without-paper/ewp-specs-api-registry/#schac-identifiers
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="receiving-ounit-id" type="ewp:AsciiPrintableIdentifier" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Optional ID of the receiving organizational unit.
This data might be relevant for some partners, while other partners might
ignore it completely. If the server is aware that particular students should be
received by a particular organizational unit, then it reports it here. Note,
that this MAY be the "root" unit (the one representing the entire HEI).
This ID is defined by the HEI referred to in the `receiving-hei-id` element.
If the server is not aware of this ID, then it won't provide it. Clients
can retrieve further information on this unit via Organizational Units API, but
note, that it is not obvious *which* Organizational Units API the client should
use. See similar notes on `iia/partner-hei/hei-id` element. Discuss here:
https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/6
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="receiving-contact" type="c:Contact" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of contacts on the receiving HEI's side, related to the mobilities based
on this specification.
Very similar to the `sending-contact` element. Please read `sending-contact`'s
documentation.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="receiving-academic-year-id" type="trm:AcademicYearId" minOccurs="1" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of academic years for which this mobility specification is required to
be in effect. (Each mobility specification can be bound to a different set of
academic years.) It MUST be a unique set of IDs (years are not allowed to be
repeated).
If one of the partner is from the southern hemisphere (so that he uses
academic years in a form of "2010/2010" instead of "2010/2011"), then IDs
provided here should refer to the scheme used by the receiving partner (not the
sending one). At the beginning of the EWP project clients MAY expect all
academic years to come in the northern hemisphere format, but this might change
later on.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="mobilities-per-year" type="xs:positiveInteger" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Maximum number of people to be sent *for each* academic year. (The total number
of people being sent can be calculated by multiplying this number and the
length of the `receiving-academic-year-id` list.)
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="recommended-language-skill" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of recommended language skills the student (or staff member) should
have at the start of the mobility period.
This element can currently be attached to all subclasses of
MobilitySpecification. Since it has almost the same meaning regardless of where
it is attached, we define it here (in the base class) for now. This MAY change
in future versions though.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="language" type="xs:language" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
The code of the language which the student (or staff member) is recommended to be
familiar with.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="cefr-level" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Optional CEFR level code - the recommended minimum level of language skill the
student (or staff member) should have.
https://en.wikipedia.org/wiki/Common_European_Framework_of_Reference_for_Languages
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[ABC][12]"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="subject-area" type="SubjectArea" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="subject-area" type="SubjectArea" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
Optional subject areas associated with this mobility.
This element can currently be attached to all subclasses of
MobilitySpecification. Since it has almost the same meaning regardless of where
it is attached, we define it here (in the base class) for now. This MAY change
in future versions though.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="other-info-terms" type="xs:string" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Optional field for any other information regarding the terms of the agreement.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="SubjectArea">
<xs:sequence>
<xs:element name="isced-f-code" type="xs:string" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
ISCED-F subject area code.
ISCED-F codes define fields of education and training at the secondary,
post-secondary and tertiary levels of education. Details:
http://uis.unesco.org/sites/default/files/documents/isced-fields-of-education-and-training-2013-en.pdf
Note: We strongly recommend that the ISCED code should be four-digit,
because this way it will be compliant with the requirements of Mobility Tool+ application,
which only accepts four-digit codes for mobilities (see issue: #49).
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="isced-clarification" type="xs:string" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
This field contains additional details regarding `isced-f-code` field.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="StudentMobilitySpecification" abstract="true">
<xs:annotation>
<xs:documentation>
A common parent class for all student mobility specifications.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="MobilitySpecification">
<xs:sequence>
<xs:element name="total-months-per-year" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Total number of mobility months per academic year.
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:decimal">
<xs:minExclusive value="0"/>
<xs:fractionDigits value="2"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="blended" type="xs:boolean" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Blended mobility option for students. By sending 'true', the partners
confirm that they are willing to exchange students who wish to carry out their mobility
in a blended format, a combination of a short-term physical mobility with a virtual
component.
Note: This field should be set to 'false' for all agreements create before the
introduction of blended mobilities.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="eqf-level" type="ewp:EqfLevel" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
A list of allowed study levels of the students being sent.
(If a particular student's level is not listed here, then this student should
not be able to apply for this mobility.)
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="StaffMobilitySpecification" abstract="true">
<xs:annotation>
<xs:documentation>
A common parent class for all staff mobility specifications.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="MobilitySpecification">
<xs:sequence>
<xs:element name="total-days-per-year" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Total number of mobility days per academic year.
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:decimal">
<xs:minExclusive value="0"/>
<xs:fractionDigits value="2"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="student-studies-mobility-spec">
<xs:annotation>
<xs:documentation>
Specifies unidirectional "Student Mobility for Studies" cooperation condition.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="StudentMobilitySpecification">
<xs:sequence>
<!-- Currently, there are no extra fields for this subclass. -->
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="student-traineeship-mobility-spec">
<xs:annotation>
<xs:documentation>
Specifies unidirectional "Student Mobility for Traineeships" cooperation condition.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="StudentMobilitySpecification">
<xs:sequence>
<!-- Currently, there are no extra fields for this subclass. -->
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="staff-teacher-mobility-spec">
<xs:annotation>
<xs:documentation>
Specifies unidirectional "Staff Mobility for Teaching" cooperation condition.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="StaffMobilitySpecification">
<xs:sequence>
<!-- Currently, there are no extra fields for this subclass. -->
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="staff-training-mobility-spec">
<xs:annotation>
<xs:documentation>
Specifies unidirectional "Staff Mobility for Training" cooperation condition.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="StaffMobilitySpecification">
<xs:sequence>
<!-- Currently, there are no extra fields for this subclass. -->
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:schema>