-
Notifications
You must be signed in to change notification settings - Fork 13
/
Copy pathget-response.xsd
751 lines (688 loc) · 43.2 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
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
<?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-v7/endpoints/get-response.xsd"
xmlns="https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v7/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` value passed in the
Interinstitutional Agreements 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 HEI id covered
by the host,
* 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),
* `iia-id` MUST match the value passed in the `iia_id` 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.
ID used by the partner MUST be provided as soon as it is mapped in the local system.
Otherwise, an agreement might be interpreted as not mapped, which may lead to duplicates.
Also, it is REQUIRED to provide a partner agreement ID so that the other partner can approve the agreement.
Yet this ID MUST NOT be present if the partner has deleted the IIA.
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 is a partner's signer of this IIA (if known).
Most often it is an institutional coordinator for this IIA,
but it could also be, for example, the dean of the faculty.
</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.
You MUST be consistent in ordering cooperation conditions as it is used to
produce the `iia-hash` value.
</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:attribute name="terminated-as-a-whole" type="xs:boolean" use="optional">
<xs:annotation>
<xs:documentation>
If given MUST be set to "true". Flags the agreement as terminated
and MUST be used only for mutually approved agreements that
the partners decide to terminate before any exchanges have taken place.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="iia-hash" type="ewp:Sha256Hex" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
The SHA-256 digest of the `text-to-hash` element content that is obtained
by using the appropriate XSLT transformation mentioned in the API specification.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="pdf-file" type="xs:string" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>
Identifier of the file containing the PDF version of the agreement.
The file MUST be accessible to the receiving HEI through the EWP File API.
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 non-abstract 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 from start to end, 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 a 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 the
EWP IIAs API. It is likely to be modified, or to be removed, in the future.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:group ref="MobilityMain"/>
<xs:element ref="recommended-language-skill" minOccurs="0" maxOccurs="unbounded"/>
<xs:group ref="MobilityAdditional"/>
</xs:sequence>
</xs:complexType>
<xs:group name="MobilityMain">
<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-first-academic-year-id" type="trm:AcademicYearId" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
The first academic year for which this mobility specification is required to
be in effect *during a given programme period* (each mobility specification
can be bound to a different set of academic years).
If one of the partners 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).
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="receiving-last-academic-year-id" type="trm:AcademicYearId" minOccurs="1" maxOccurs="1">
<xs:annotation>
<xs:documentation>
The last academic year for which this mobility specification is required to be in effect.
This academic year MUST NOT precede the `receiving-first-academic-year-id`.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="mobilities-per-year" minOccurs="1" 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
number of the academic years this mobility specification is required to
be in effect (see `receiving-first-academic-year-id` element documentation).
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:positiveInteger">
<xs:attributeGroup ref="not-yet-defined"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:group>
<xs:element name="recommended-language-skill">
<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 is currently attached to all subclasses of
MobilitySpecification. Since it has almost the same meaning regardless of where
it is attached, we define it here 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.
Note: EWP is following BCP 47 (https://www.rfc-editor.org/rfc/bcp/bcp47.txt)
for specifying languages but disallows the use of special codes mentioned in
chapter 4.1. Choice of Language Tag, guideline 5 of this document.
</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
It is strongly RECOMMENDED to provide this element, and it will be
mandatory in the future version of the API.
</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:attributeGroup ref="not-yet-defined"/>
</xs:complexType>
</xs:element>
<xs:group name="MobilityAdditional">
<xs:sequence>
<xs:element name="subject-area" type="SubjectArea" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
Optional subject areas associated with this mobility.
This element is currently attached to all subclasses of
MobilitySpecification. Since it has almost the same meaning regardless of where
it is attached, we define it here 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:group>
<xs:complexType name="SubjectArea">
<xs:sequence>
<xs:element name="isced-f-code" 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:
https://uis.unesco.org/sites/default/files/documents/isced-fields-of-education-and-training-2013-en.pdf
Note: ISCED code MUST be four-digit,
to be compliant with the requirements of the Beneficiary module,
which only accepts four-digit codes for mobilities (see issue: #49).
Agreements mutually approved before IIA version 7 that had ISCED code with less than four digits
MUST have ISCED code replaced with a proper four-digit ISCED code and
MUST have `v6-value` attribute set to the previous ISCED code approved in version 6.
After IIA version 7 is implemented and the agreement is modified the ISCED code
MUST be set by the end-user and the attribute MUST be removed.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="isced">
<xs:attribute name="v6-value" use="optional">
<xs:annotation>
<xs:documentation>
Value of this field as of IIA version 6.
This attribute:
* MAY be set only for mutually approved agreements that
have been approved in IIA version 6 and have not been modified since,
* MUST be set for agreements that had ISCED code with less than four digits,
* MUST NOT be set otherwise.
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]{1,3}"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</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.
It MUST be an empty string if a more precise description is not needed.
You MUST NOT put the official name of the ISCED in this field.
Nevertheless, if the agreement has been mutually approved in IIA version 6
and has not been modified since, then this field MUST be unchanged.
</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:group ref="StudentMobilityExtension"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:group name="StudentMobilityExtension">
<xs:sequence>
<xs:element name="total-months-per-year" minOccurs="0" 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 created 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>
Allowed study levels of the students being sent.
Note: If at least one EQF level is provided here and student's level
is not one of these levels, then such a student SHOULD NOT be able to apply
for mobility specified by these cooperation conditions.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:group>
<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:group ref="StaffMobilityExtension"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:group name="StaffMobilityExtension">
<xs:sequence>
<xs:element name="total-days-per-year" minOccurs="0" 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:group>
<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:restriction base="StudentMobilitySpecification">
<xs:sequence>
<xs:group ref="MobilityMain"/>
<xs:element ref="recommended-language-skill" minOccurs="1" maxOccurs="unbounded"/>
<xs:group ref="MobilityAdditional"/>
<xs:group ref="StudentMobilityExtension"/>
</xs:sequence>
</xs:restriction>
</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:restriction base="StaffMobilitySpecification">
<xs:sequence>
<xs:group ref="MobilityMain"/>
<xs:element ref="recommended-language-skill" minOccurs="1" maxOccurs="unbounded"/>
<xs:group ref="MobilityAdditional"/>
<xs:group ref="StaffMobilityExtension"/>
</xs:sequence>
</xs:restriction>
</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:attributeGroup name="not-yet-defined">
<xs:attribute name="not-yet-defined" type="xs:boolean" use="optional">
<xs:annotation>
<xs:documentation>
If given MUST be set to "true". Flags an element value as not yet defined
and MAY be set only for mutually approved agreements that
have been approved in the old IIA API version and have not been modified since,
and MUST NOT be set otherwise.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:attributeGroup>
<xs:simpleType name="isced">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]{4}"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>