erasmus-without-paper / ewp-specs-api-iias Goto Github PK

@erasmus-without-paper/all-members

EUC IIA template defines 4 types of mobility. For each type, it also specifies the unit in which mobility duration is to be measured:

• Student mobility for studies - months
• Student mobility for traineeships - months
• Staff mobility for teaching - days
• Staff mobility for training - days

1. Is this also what your systems expect?
2. If not, would you be willing to make your systems expect that?

Alternate solution would be to allow both duration units, regardless of the mobility type. But I'm not sure if this would be compatible with EUC requirements?

Some of the elements of an IIA are allowed to change in the course of the agreement, such as mobilities-per-year.

Such changes could be added as amendments to the agreement. In this proposal we will try to stay as close as possible to the current model, that the IIAs are read-only and distributed, and discussion on changes is done through some other medium, e.g. telephone or e-mail. However, miscommunication is always a possibility and errors may need to be corrected. The API must allow for such corrections.

Each amendment has a validity period, and some changes.

The element amendment would not contain all the elements from student-studies-mobility-spec, but only those that are allowed to be changed.

Approval can be supported by the same method as approving the entire IIA as proposed here. E.g. choosing method I from this issue, approval can be supported by including a status associated with the SCHAC-code of the approving partner. Initially one HEI would send a notification to the partner that the IIA has changed. The partner retrieves the IIA with the new amendment, already approved by the initiating partner. If the other partner agrees, it adds an approval element with its own SCHAC-code and sends a notification. If it does not approve, it discussed with the partner (e-mail or telephone), and eventually a new amendment may be added.

There can be several amendments, for different academic years. If there are conflicting amendments for the same year, these need to be resolved by one of the partners rejecting one of the amendments. An id facilitates identifying an amendment. This can be anything, but prefarably a UUID. It is not allowed to change approved amendments otherwise than rejecting it. Only new ones can be added, possibly overriding a previous one, which must be rejected.

Early termination of the agreement would be accomodated by reducing the mobilities-per-year to 0 for the remaining years.

In xml this proposal would look like this (only showing the relevant elements, using method I from the proposal for supporting status

<iaa>
    <partner>
        <hei-id>uw.edu.pl</hei-id>
    </partner>
    <partner>
        <hei-id>ugent.be</hei-id>
    </partner>
    <cooperation-conditions>
        <student-studies-mobility-spec>
            <receiving-academic-year-id>2014/2015</receiving-academic-year-id>
			<receiving-academic-year-id>2015/2016</receiving-academic-year-id>
			<receiving-academic-year-id>2016/2017</receiving-academic-year-id>
			<receiving-academic-year-id>2017/2018</receiving-academic-year-id>
			<receiving-academic-year-id>2018/2019</receiving-academic-year-id>
			<receiving-academic-year-id>2019/2020</receiving-academic-year-id>
            <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
            <mobilities-per-year>2</mobilities-per-year>
         </student-studies-mobility-spec>
    </cooperation-conditions>
    <amendments>
        <amendment id="152929a8-e487-4b59-ad90-35c22985668e">
			<receiving-academic-year-id>2016/2017</receiving-academic-year-id>
            <mobilities-per-year>10</mobilities-per-year>
            <current-status>
                <partner-id>uw.edu.pl</parnter-id>
                <status>APPROVED</status>
            </current-status>
            <current-status>
                <partner-id>ugent.be</parnter-id>
                <status>APPROVED</status>
            </current-status>
        </amendment>
        <amendment id="42a238a1-f08c-4b92-b3e6-bea0e31b84ab">
			<receiving-academic-year-id>2017/2018</receiving-academic-year-id>
            <mobilities-per-year>5</mobilities-per-year>
            <current-status>
                <partner-id>ugent.be</parnter-id>
                <status>APPROVED</status>
            </current-status>
        </amendment>
    </amendments>
</iia>

I have just noticed, that there are no start/end dates on the EUC IIA template. We have included them in the XSD, because we have them in the model. But do we actually need these dates?

Or, perhaps they should be optional?

Or, we should replace them with academic year references? (We already have those in <cooperation-confiditions> though, so this would be somewhat redundant.)

@erasmus-without-paper/all-members

Following is the definition of "student-studies-mobility-spec"
<xs:element ref="student-studies-mobility-spec" minOccurs="0" maxOccurs="unbounded">

It means that it can be repeated. In case it is repeated can someone tell me how can I identify the unique key. Is combination of sending-hei-id,receiving-academic-year-id unique?

Hi,

REF:

In the reference above, it is stated that minOccurs=0
That means it is not required to send this information in iia-get responses.

However, the explanation says that

(If a particular student's level is not listed here, then this student should not be able to apply for this mobility.)

This seems to conflict with the not required state of the EQF info.

If I did not misunderstand this, then how will it be possible to restrict students to use this iia in their applications when no EQF information exists in the IIA?

Could anybody please comment on this and clarify the explanation?

Is there an ambiquity or do we misunderstand the explanation?

And how the EQF level/s should be interpreted if they do not exist in the IIA get content?

Thanks,

I am implementing the IIA API now and wondering about what was the idea of an workflow that would get data into the database in the first place. It seems that both partner/iia-id and partner/iia-code are optional.

Let's say that Warszawa (UW) and Oslo (UIO) want to establish an IIA. My understanding is that, for now, this would be done outside of EWP? In that case, IIA_IDs on both sides are unknown and UW and UIO need to exchange their IIA_CODEs in order to be able to refer to the same IIA at a later point. However, if IIA_CODE is optional, how are they going to do that?

Let's assume that neither have a code. UIO can call UW's /iias/index to get a list of IIAs. It finds an IIA with IIA_ID='UWUIO1'. It then calls /iias/get?iia_id=UWUIO1 - but there is no way to match that IIA with Oslo's local one without codes that BOTH sides know in advance.

Shouldn't both partner/iia-id and partner/iia-code be mandatory?

In IIA API is supposed to be in format of receiving institution. Is there a API that tells in what format the receiver institution is accepting the academic year? If not, then how will sender institution know the format?

• Element "condition" should be renamed to "cooperation-condition"
• Element "term" should be renamed to "academic-term", and "title" should be split into "year" and "term" (suggest we standardize on the start year)
• Element "mobility-type"
  • Should be standardized to the following alternatives (in some coding scheme):
    • Student/Studies
    • Student/Traineeships
    • Staff/Teaching
    • Staff/Training
  • Maybe it's best to split into two fields, e.g:
    • "mobility-group" (Student,Staff)
    • "mobility-type" (Studies,Training)
  • Giving the following combinations:
    • Student/Studies
    • Student/Training
    • Staff/Studies
    • Staff/Training
  • Why does this element have maxOccurs unbounded?
    • That would imply n Cooperation Conditions with different mobility-types but the same values in the other components (IIA Id, Institution Id, Org Unit Id, Year/Term and Subject Area Code)?
    • In my opinion, the unbounded attribute on "(cooperation-)condition" is sufficient
• Element "subject-area" should be named "subject-area-code" to conform to the model and to differentiate from the entity identified by it
• Element "id" is presumably = IIA Id
• The following elements from the model are missing:
  • "mobility-number"
    • Maybe it should be repeated by a "direction" attribute (Incoming/Outgoing)?
  • "req-lang-comp" repeated by a "lang" attribute (moved from Organization Unit)
  • "eqf-level"
    • I assume this is = Study Cycle?
    • What is the coding scheme for this?
  • "local-iia-id" (optional)
  • "coordinator(s)" should probably be included here
    • "iia-id"
    • "institution-id"
    • "organization-unit-id"
    • "person-id"
    • "role-id"

Hi,

In the XSD page below, it is given a reference link to the CEFR definitions.

Is there a similar reference link (ISO standard codes or similar?) for language codes to be used in IIA API?

We think including such data definition reference links would be good for knowing which standards to use.

Thanks,

<xs:element name="total-months-per-year" minOccurs="1" maxOccurs="1">
<xs:element name="total-days-per-year" minOccurs="1" maxOccurs="1">

The total months per year and the total days per year elements are defined as decimal numbers in the specs.

We need some clarification on these definitions:

• What does it mean if the "total months" is given as 7.33? How shall this be interpreted by the HEI?

• Is it possible to give 15.80 as total days? And if yes, what does it mean? How shall this be interpreted by the HEI?

• What is the point and intention in having this information in decimal number format?

Having made many many IIA tests meetings (provider-to-provider, HEI to HEI, provider to HEI, and vice versa), we have seen only one provider requires and sends decimal number. And the rest uses integers.

Also, I think that this is just another point that causes the hash calculation differences between software.

We will be happy if somebody can clarify this issue for us?

We are developing the new IIAS template right now and we have a problem with the blended field. This field is at the agreement level,neverthelesin the GET API the same filed operate for each Student Mobility for Studies.

That's a contradiction, isn´t it?

Can any partner submit a change notification (cnr) again after the partners have approved the agreement?
Or can submit a change notification (cnr) again our agreement approved by the partner?

@wrygiel :
Shouldn't there be an optional ounit-id at the top and partner-hei levels, as IIAs can have OUnits as Partners?

In the get-response.xsd of ewp-specs-api-iias the element subject-area is part of recommended-language-skill. Is that ok?

We may need some changes in the IIAs API and maybe also in other EWP APIs according to the new template of the interinstitutional agreements.

The new template is available here and here.

At UW we have fractional numbers in both average (total) months and average (total) days for student and staff mobilities respectively but avg(total)-days and avg(total)-months are defined as integers.

@erasmus-without-paper/all-members, could we allow fractional numbers in those fields?

I'm having a hard time understanding how B is supposed to behave in the example.

Starting with the following examples:

• 2 HEIs can negotiate an arbitrary number of active IIAs between the 2 of them

Step 3 states: "B agrees with the version sent by A"

Now, how is B supposed to link its own version of the IIA to A's version of the IIA? Is this meant to be a manual interaction on B's side?

Furthermore: in step 6 B suddenly knows, that its own 79364 is the counterpart for A's 0f7a5682-faf7-49a7-9cc7-ec486c49a281. Again: is this determined by manual human interaction with B's system?

Finally: How is all of this supposed to work if one (or both) HEI does not implement ewp-specs-api-iias-approval? The statement here together with minOccurs="0" leads me to believe ewp-specs-api-iias-approval is not mandatory.

Hi all,

I'm unsure if this is the right place to ask this question, so please refer me to another spot if that is more relevant!

I'm wondering if a personal/custom message for the partner can be attached when submitting an IIA proposal/change. This is important for the 'human' connection and relationship that plays a part in negotiating an agreement. The alternative would be that the 'negotiation' is done via e-mail and only the signing is done via EWP.. but I'm under the impression that it would be more valuable if the whole process is supported. However, perhaps there are valid reasons why EWP should not be functioning as an 'instant messaging service' or replacing e-mails ;).

Would love to hear your thoughts on this, or be referred to a previous discussion if this has already been discussed.

Thanks!
Evelien Renders (Radboud University, the Netherlands)

As briefly discussed in the last meeting an issue was brought to our attention, that some Universities may want to terminate or reject IIAs in addition to the approval ( #30 ).
This cannot be done at the moment in a clean way.
How would you handle termination / rejection?

1. Send a CNR and set in-effect to false? - maybe for termination, but what about rejection?
2. Send a CNR and remove all cooperation-conditions? - could be very misleading.
3. Add possibility for terminate / reject to the approval API?
4. Just flag them internally and ignore them forever / e-mail the partner?

As you can see here, we are currently using academic-year lists in mobility-specs. But perhaps there should rather be replaced with "academic-year spans"?

In other words, instead of writing this:

<receiving-academic-year-id>2014/2015</receiving-academic-year-id>
<receiving-academic-year-id>2015/2016</receiving-academic-year-id>
<receiving-academic-year-id>2016/2017</receiving-academic-year-id>
<receiving-academic-year-id>2017/2018</receiving-academic-year-id>
<receiving-academic-year-id>2018/2019</receiving-academic-year-id>
<receiving-academic-year-id>2019/2020</receiving-academic-year-id>
<receiving-academic-year-id>2020/2021</receiving-academic-year-id>

We would write something like this:

<receiving-academic-years>2014/2015-2020/2021</receiving-academic-years>

Both format can be mapped on each other quite easily, but I somehow feel that the latter one would fit more consistently with the models used in partners' databases.

IIAs can be multilateral. Is that the case for Cooperation Conditions as well?
I.e. if there are 3 Partners in an IIA, can a Cooperation Condition be three-way?

There are fields in the cooperation coditions that are not in the IIAs template. Those are:

• sending-contact
• receiving-contact
• sending-ounit-id
• receiving-ounit-id

Recently, there has been the idea that certain fields should be removed from the conditions-hash computations, because changing these fields would change the hash, but they do not contain information that should affect the validity of the agreement.

We believe that this should apply to fields sending-contact and receiving-contact, as the contact details of cooperation coordinators can indeed change.

However, we believe that the hash should take into account the field sending-ounit-id and receiving-ounit-id, because the faculties implementing cooperation conditions are unlikely to change. And if this happens (or the name of the organizational unit changes due to changes in the structure of the university), a new agreement should be signed in such a case.

Please comment if you think we should do it differently.

During the technical workshop in Warsaw we were asking ourselves why the subject area code wasn't obligatory in the IIA template of the European Commission. Our colleagues now came back to us and informed us that the reason is that the agreements were published at the moment where there was a transition between the different ISCED systems (as discussed during the workshop as well).

The EC is open to make the field obligatory and that the EWP could make recommendations in that directions if deemed necessary.

I personally don't see a need for having those codes a a necessary field. We of course need to include them as a possible data set (currently already part of WP3's data model). In the guidelines for implementation we can point out that we encourage institutions to include this field as it will greatly help the understanding of what students can be sent between different departments/faculties.

What do the others think? I am especially interested in the opinion of the practitioners @pleys

E.g. we have a case with 3 mobilities and a total of 10 months.
When expressed as an avg-int you lose 1 month.

I'd suggest using the total-months, since the avg-months could be computed more precisely.

In the IIA there is an element <xs:element name="organization-unit-id" type="xs:string"/>. Should this be department-id from the Departments API? We should have the same terminology.

Does the iia conditions-hashes values presented in the examples across the IIAs spec correspond to the ones that are actually expected?
Because I could not reproduce the
https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v6/example-scenario/01-A-get-response.part.xml#L31
for the specific cooperation-conditions.

The only documentation about how to calculate the conditions-hash is the following:

          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.

Should the element be formatted? Should we ignore whitespaces in element content (like carriage returns)?

In my humble opinion, a get response example followed by the actual string that needs the SHA-256 is needed in order to clarify and test implementations.

At my university, we are struggling when integrating with several implementations from different vendors (QS, SOP, Erasmus Dashboard...) and having a reference test example would help a lot.

Hi,

We need verification for the following issue from the maintainers.

REF:

On the REF link, it says maxOccurs =1 for the isced code.
<xs:element name="isced-f-code" type="xs:string" minOccurs="1" maxOccurs="1">
And it as it says for the subject area maxOccurs=unbounded and the isced code is inside this tag.
<xs:element name="subject-area" type="SubjectArea" minOccurs="0" maxOccurs="unbounded">

If this is the case, the following code is possible?
I mean you can have only one "isced-f-code" inside a "subject-area".
But you can have the subject-area section many times for different isced codes under one mobility condition spec?

<staff-teacher-mobility-spec>
     <mobilities-per-year>2</mobilities-per-year>
     <total-days-per-year>8</total-days-per-year>
     ...
     <subject-area>
         <isced-f-code>0314</isced-f-code>
     </subject-area>
     <subject-area>
         <isced-f-code>0425</isced-f-code>
     </subject-area>
     <subject-area>
         <isced-f-code>0922</isced-f-code>
     </subject-area>
</staff-teacher-mobility-spec>

Scope: supporting the process of approving an IIA.
Out of scope: Discussion about the contents.

We have two different proposals. Of course, EWP should support only one method, either one of those below, or another one that evolves from these after discussion.
In both methods we follow the principals of this issue. We stick to IIA3 distributed, no-master, meaning that everybody is master of its own data. And this data can be duplicated by both parties.

Method I

Approval can be supported by including a status associated with the SCHAC-code of the approving partner in the current IIA API.
One of the partners enters the data into its system, and sends a notification to the partners. The IIA at that point contains an approval status from that one partner.
If the other partners agree, they enter the data in their system, and add their own approval status. A notification is sent to the partners.
The partners that have already approved, compare if the contents of the IIA they have in their local system is equal to the one the notification is sent for. If it is, the approval by the other partner is recorded in their local system. If it is not, the local system must report an error, and discussion should follow through some other medium.

In multilateral agreements, at a certain time the different partners may have different sets of approving partners, as notifications are being sent and processed. However, since the data itself is never changed, and approvals are only being added, this will stabilize after a little while.

In xml, the status element should contain the status APPROVED (different statusses may be needed in the future, see also the proposal about amendments), and the SCHAC-code of the approving partner.
If necessary, this element would be the place to add a signature of the approved data.

Example.

Suppose X and Y have agreed upon a proposal, and X first enters the data.
The iia element would look like this (only the relevant elements are included):

<iia>
    <partner>
        <hei-id>X</hei-id>
    </partner>
    <partner>
        <hei-id>Y</hei-id>
    </partner>
    <current-status>
        <partner-id>X</parnter-id>
        <status>APPROVED</status>
     </current-status>
</iia>

After review, Y adds its own status:

<iia>
    <partner>
          <hei-id>X</hei-id>
    </partner>
    <partner>
          <hei-id>Y</hei-id>
    </partner>
    <current-status>
          <partner-id>X</partner-id>
          <status>APPROVED</status>
    </current-status>
    <current-status>
          <partner-id>Y</parnter-id>
          <status>APPROVED</status>
     </current-status>
</iia>

Method II

The approval proces could be considered a pattern that we will probably need more often. Maybe we can treat it in a general way like we have CN. We actually have an example already with the mobilities.
The difference between IIA and mobitilies is that incoming mobilities that are not communicated through the network, remain invisible to the network. Therefore every mobility is known by one ID inside the network. In the case of IIA both parties can expose the same IIA with different ID's. However, they should use the same IIA-code.

The approval proces consists of:

• one of the parties, the initiator, makes a proposal
• there can be different versions of the proposal
• all collaborating parties approve or reject a specific version of the proposal
• there can be remarks on a specific version of the proposal

So in addition to the IIA and CNR-API we would need an API with corresponding CNR-API that we can use to report the status of the IIA.
The API could expose an entity like StatusUpdate(datetime of the statusupdate, hei-id of the status,surrogate-id of the IIA, version, comment, status).
Each HEI remains the master of its decision about the IIA, i.e. whether it approved or rejected the proposal

Example.

Initiator X creates IIA with surrogate ID "X-1" and version 1 and sends a IIA-CN to all partners (there is a single partner Y in this example).

Collaborator Y receives IIA-CN, creates

<status-update>
	<timestamp>2019-08-30T16:35:00Z</timestamp>
	<hei-id>Y</hei-id>
	<iia-id>X-1</iia-id>
	<version>1</version>
	<comment>Didn't we agree on three years in stead of 5?</comment>
	<status>REJECTED</status>
</status-update>

and sends a StatusUpdate-CN to all partners

Initiator X receives the StatusUpdate-CN and updates IIA and sends a IIA-CN for version 2 to all partners.
Collaborator Y receives IIA-CN, creates

<status-update>
	<timestamp>2019-08-31T17:35:30Z</timestamp>
	<hei-id>Y</hei-id>
	<iia-id>X-1</iia-id>
	<version>2</version>
	<comment>Great Job</comment>
	<status>APPROVED</status>
</status-update>

and sends a StatusUpdate-CN to all partners

Initiator X creates

<status-update>
	<timestamp>2019-08-31T18:10:00Z</timestamp>
	<hei-id>X</hei-id>
	<iia-id>X-1</iia-id>
	<version>2</version>
	<comment/>
	<status>APPROVED</status>
</status-update>

and sends a StatusUpdate-CN to all partners

It is possible that two hei's X and Y create an IIA that are in fact the same. In that case they can agree to approve only the one from X or only the one from Y, or both.

I am opening a new issue just to be recorded here in the processes.

I noticed during the full integration of the Dashboard with the EWP network that the two fields below do not match entirely.

1st. ISCED-F-Codes which in the EWP is defined to exist only 1 maximum or none and we allow multiple selection of isced-f-codes.

2nd. EQF-Level which in the EWP is defined to exist at least one to an unlimited number and in the template says it can be optional.

Is it possible to make these changes in the definition?

Perhaps we should add a signing date to the IIA (the date at which the IIA has been signed by all parties)? Is this information stored by most of the partners? @erasmus-without-paper/all-members

Developers from Poland proposed making the mobilities-per-year element optional. They say this will not "hurt" Erasmus agreements, and it would allow IIAs API to be used to exchange information about any agreements (not only Erasmus ones).

@erasmus-without-paper/all-members - would any of you want to use such feature? Would you expose non-Erasmus IIAs?

Personally, I am confused. I'm afraid that these non-Erasmus agreements might have entirely different structure/model than the Erasmus ones. If so, then extending IIAs API in this direction seems a bad idea. I'm not an expert on the topic though.

• Are all these non-Erasmus agreements always related to mobilities?
• If so, then are all these mobilities limited to the same set of 4 types which Erasmus agreements defines?
• Can all of them have optional "recommended-language-skill" and/or "isced-f-code"?
• Do we need to distinguish between Erasmus and non-Erasmus IIAs? Some kind of agreement-type?

During our tests with universities the following problem came up:
For some universities the ISCED code is not enough to specify the agreements.
They have their agreements on a study field level and multiple study fields per ISCED code which may not be related at all. The Study fields of one ISCED code may be distributed among multiple faculties and different agreements for different study fields of the same ISCED code may be present.
With the Agreements on ISCED level multiple identical IIAs would exists, IIAs could not be correctly matched to local Agreements and partners could not predict if an exchange for a specific study field of the ISCED code is possible.

For example two identical IIAs for ISCED code "0231 - Language acquisition" could exist.
One for German, one for English. Now 0231 covers about 30 Languages and exchange students won't be accepted for 28 of them. The study fields are also part of the official agreement documents of these Universities.

I'd propose some sort of additional information or comment field(s) on coop-conditions to further restrict / specify the coop-condition.

Currently, the IIA get response defines many elements "two times" - once for the local partner (e.g. here), and once for the remote partners (e.g. here).

Of course, these are often stored in separate entities in local databases, but perhaps making this separation on the representation level is somewhat confusing? Perhaps it would be easier to read the specification, if we simply had a <partner> element for the local partner too?

@erasmus-without-paper/all-members

We tested the exchange of IIAs via EWP with one of the partner universities. When we downloaded the agreement, it turned out that the partner assigned the three-digit ISCED code to cooperation conditions. We couldn't save it in our system because we only have more detailed four-digit codes in our dictionary.

The IIAs pattern published by the EC says nothing about the detail of the ISCED code, but I have never come across a three-digit ISCED code from our partners. Which does not change the fact that perhaps they should be allowed.

Do you think we should allow only four-digit ISCED codes, or should we allow codes with a different number of digits - three-digit and/or two-digit?

Should the decision we make here also apply to all other places in the EWP where an ISCED code appears?

It seems that neither start_date and end_date are defined as part of get-response (they should be at least inside <partner/> but possibly also <iia/> itself). Have I missed something?

The XSD states:

minOccurs="0" maxOccurs="unbounded"

Example states:

At least one eqf-level is required for "mobility for studies".

Hi all,

We would like to verify the total months calculation for our IIA data to be published via EWP and therefore needs a sample formula and verification for our following calculation below.

Here is the definition reference for total months.

And here is the sample XML for iia-get response:

Q1: Does the total months given in the above xml response reflect a correct result/calculation/formula?

Q2: What is the duration in months per person per academic year in the above xml response?

Q3: Is the following calculation correct?

• We have 4 mobilities per year.

• Each mobility duration is 4 months.
  => That makes 16 months in a year. 

• The agreement is valid for 4 academic years. 
  Shall we print 64 months (4 academic years X 16 months)?

Thanks in advance,

Currently (v0.5.0) the index endpoint doesn't allow filtering by partner HEI, and the server MAY return all his IIAs, regardless of who's asking.

It seems reasonable to add a partner_hei_id parameter which would allow for such filtering.

IIA API allows only 1 isced-f-code (<xs:element name="isced-f-code" type="xs:string" minOccurs="0" maxOccurs="1">) at a time? Any particular reason for this restriction? What to do if the agreement allows more then 1 ISCED code?

XML Schema Validator seems to stop working on get response example in version 4.0.0:

(#1) cvc-elt.1.a: Cannot find the declaration of element 'iias-get-response'.

Should in-effect stay true after the end of IIA? Currently the specs are not explicit about this.

Currently Instutions API returns information only about the HEIs covered by the host serving this API. However, IIAs may refer to other HEIs too. This might be a problem, because the client won't be able to retrieve data on these HEIs (even the basic data, such as HEI's name).

Possible solutions:

1. Include HEIs' names in IIAs API.
2. Allow to describe these HEIs via Institutions API.
3. Limit HEIs exposed via IIAs API to EWP HEIs only.

@erasmus-without-paper/all-members

@janinamincer-daszkiewicz suggested that we might add a server-side date filter to the IIAs index endpoint. I don't yet see if this would be useful, and how exactly this would work (I feel like it should be rather filtered on the client side).

I see below issue raise earlier
#12

And it was decided that the list will be kept because 2 of the partners keep list in their system.

I just wanted to check if the list will be in sequence always, so that partners who are using span can easily take first and last entry. If not the may be we should re-look to pass it in span and not list

When it comes to expressing timespans, currently, IIA sections in XSD are compatible with the EUC IIA PDF template. In particular, <staff-teacher-mobility-spec> contains the <avg-days> element, which was meant to express the "average duration" mentioned here in the PDF:

However, I am not really sure if the EUC IIA template really conforms to the "real-life practices". For example, our IRO claims that these should be expressed in hours, or in weeks, and that "8 hours" are equivalent to "1 week". Honestly, I don't understand much of it. Do we have an expert who could explain this model?

I would rather NOT include <staff-teacher-mobility-spec> in the specification, than include it with a wrong model.

@erasmus-without-paper/all-members

Something to think about. Perhaps in EWP 2.0?

It has been proposed that partners could optionally serve scanned PDFs of actually signed IIAs, via EWP.

This would be easy to add, but I think we should wait with this until at least a couple of partners agree that they would serve and/or fetch it. We don't want to clutter our APIs with unused features.

@janinamincer-daszkiewicz suggested that IIAs should have a field for a short comment. Before IIAs are matched with their remote counterparts, such extra field could make it easier to determine which IIA is which.

I myself am not sure about this. I don't see much added value. I think IIA's code should be enough - it can be passed via email from one IRO member to the other. It can even by a temporary code (and be changed to the official one after IIA is signed), because codes are allowed to change freely.

@erasmus-without-paper/all-members

@erasmus-without-paper/all-members

1.0.0 versions of IIAs API and IIA CNR API

I think it's time to release the stable versions of IIAs API and IIA CNR API. I can see that many partners have already implemented IIAs API, so I guess they have also cross-validated the specifications, and we may consider them stable. IIA CNR API hasn't been implemented, but I think we can make it stable too (because these two are much related).

Bump all other XML namespaces to stable-v1?

Quote from the Working with EWP Technical Documentation document (version 1.2.0). This was changed recently:

Unreleased (draft) APIs also SHOULD use valid GitHub URLs for theirs XML
namespaces. They MAY use URLs referring to the master branch, but they
also MAY use URLs referring to the - not yet existing - stable-v1 branch
(for forward-compatibility). This DOES NOT mean that you can have draft
changes in stable-v1 branch - it only means that you can use stable-v1
XML namespace in your master branch.

In fact, I now think it was a bad decision to have master XML namespaces in the beginning. We should have started with stable-v1, not master. Note, that this does not prevent us from introducing backward-incompatible things in 0.x.y versions. It does however allow us to migrate from 0.x.y version to 1.0.0 version without much of a hassle.

That said, I think it might be a good idea to perform this action now (changing master to stable-v1 in all XML namespaces), without marking the APIs themselves as stable yet (they will still be 0.x.y). This, of course, would break some implementations, so we should schedule some specific date for that action (we would ask all developers to switch to the new namespace on this date). When would be a good time for that?

We supposed that is not quite exact procedure for counting "conditions-hash".

If you name the namespace differently (not c, ewp, trd, etc.) than in the XSD (get-response.xsd) in XML, which you can and nothing prevents, "conditions-hash" will not be the same for partners.

The data is exactly the same, but the "conditions-hash" does not fit!

The XML-C14N function (in exclusive form) performs XML normalization, but does not remove prefixes from individual elements. As a result, the hash function does not return the same fingerprint.

This seems to be a problem in architecture design.