Comments on response*.xsd

[kaiqu]

• I don't know what's meant to be the difference between response.xsd and response_new.xsd, so I comment on both together (maybe some of the missing elements are supposed to be in one and not the other, or the optionality varies)
• Seems to be a combination of Person Mobility and Learning Agreement
• Element "timeline" needs to be discussed, as Wojciech has mentioned
  • It seems to represent Learning Agreement (with underlying LA Components), which I think is a better name for it
  • I have used the term "learning-agreement" in my comments below
• Element "id" = Person Mobility Id, I assume
• Element "agreement-id" should be renamed to "iia-id"
• Element "given-names" should be renamed to "first-names"?
• Element "bday" should be renamed to "birth-date"?
• Element "gender" must be optional
• Element "citizenship" should be renamed to "nationality" and must be optional
• Element "rec-lang-comp" should be renamed to "lang-comp" (this is an actual competence, not a required one) and must be optional
• Element "learning-opportunity-specification" should be
  • renamed to "(learning-agreement-)components" containing "component" repeated, which contains the rest of the component elements:
  • "component-id" (or maybe "planned" could serve as identifier?)
  • "planned" (mandatory)
  • "recognized" (optional)
  • "recommended" (optional)
  • enclosed by a "learning-agreement" element (optional, repeated by a "revision" attribute), also containing:
  • "signature-date"
  • "document-id" (optional)
• Element "planned" should be mandatory
• Element "recognized" should be optional
• Element "learning-opportunity-specification-id" should be renamed to "...-code"
• Elements "start-term" and "end-term" should be split into "year" and "term"
• Element "title" should be repeated by a "lang" attribute
• The following elements from the model are missing:
  • "person-id"
  • "mobility-type"
  • "subject-area-code"
  • In the model, there is a unique Subject Area connected to a Person Mobility
  • I am not sure how this correlates with the (possibly multiple) Subject Areas connected to the underlying LA Components
  • In "(learning-agreement-)component"
  • "success" (optional)
  • "credits" (optional)
  • "grade" (optional)
• Are the following Person Mobility elements supposed to be in a separate API? In that case, which one?
  • "arrival-date" (optional)
  • "departure-date" (optional)

[wrygiel]

Seems to be a combination of Person Mobility and Learning Agreement

Even more - a "Mobility object" should describe "whole of the mobility". This includes descripion of the student, his nomination, optional Learning Agreement, and some other stuff, and the history of all changes to this mobility.

Please find some time to read this document: https://github.com/erasmus-without-paper/ewp-specs-mobility-flowcharts/

[wrygiel]

Please find some time to read this document: https://github.com/erasmus-without-paper/ewp-specs-mobility-flowcharts/

BTW - this document is still a draft (v0.3.0 currently). Big sections of it may change, depending on the models/XMLs/XSDs we discuss in Warsaw. But it is up-to-date with our (WP4's) current understanding of how things should work.

[kaiqu]

Seems to be a combination of Person Mobility and Learning Agreement

Even more - a "Mobility object" should describe "whole of the mobility". This includes descripion of the student, his nomination, optional Learning Agreement, and some other stuff, and the history of all changes to this mobility.

I was being imprecise - I also meant the underlying LA Components + some Person information. Since LA contains Revision, change history is present as well.

[kaiqu]

Here are the remaining sub-issues.

• Notes on "schemafying" the examples (where the examples don't contain the information themselves):

• Element "gender" must be optional
• Element "citizenship" [...] "nationality" [...] must be optional
• Element "learning-opportunity-specification" [...]
  • "component-id" (or maybe "planned" could serve as identifier?)
  • "planned" (mandatory)
  • "recognized" (optional)
  • "recommended" (optional)
• Data model question:

In the model, there is a unique Subject Area connected to a [Person] Mobility I am not sure how this correlates with the (possibly multiple) Subject Areas connected to the underlying LA Components

• Format question:

Are the following [Person] Mobility elements supposed to be in a separate API? In that case, which one?

• "arrival-date" (optional)
• "departure-date" (optional)

[kaiqu]

Remaining sub-issues (not handled in examples):

Data model question: In the model, there is a unique Subject Area connected to a Mobility. How does this correlate with the (possibly multiple) Subject Areas connected to the underlying LA Components?

Format question: Are the following Mobility elements supposed to be in a separate API? In that case, which one?

• "arrival-date" (optional)
• "departure-date" (optional)

[wrygiel]

I think we have agreed that arrival and departure dates will be stored in the Outgoing Mobility API (on the sending HEI's servers). They will be provided by the receiving HEI by calling Outgoing Mobility Remote Update API.