search

erasmus-without-paper / ewp-specs-api-iias

Specifications of EWP's Interinstitutional Agreements API.
MIT License
4 stars 13 forks source link

Sub-elements in case of the not-yet-defined attribute #133

Closed jiripetrzelka closed 10 months ago

jiripetrzelka commented 1 year ago

https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/3e9516dba162fb5c117fb0354cbe70add02f0428/endpoints/get-response.xsd#L471

If the not-yet-defined attribute is set to true for the recommended-language-skill element, is it forbidden for this element to contain any sub-elements?

jiripetrzelka commented 1 year ago

Since the language sub-element has minOccurs="1", it is apparently not possible. So how do I express that no language has been defined yet for SMS and STA in version 7?

Like this?

<recommended-language-skill not-yet-defined="true">
  <language>xy</language>
</recommended-language-skill>

What should I put instead of xy?

mkurzydlowski commented 1 year ago

As in the example: https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/v7.0.0/resources/xsltKit/get-response-v7.xml#L46-L49 You need to define a value but it doesn't matter what it is as long as it is valid in the XSD. The same is true for mobilities-per-year element.

jiripetrzelka commented 1 year ago

Ok, so this is also allowed?

<recommended-language-skill not-yet-defined="true">
  <language>en</language>
  <cefr-level>B1</cefr-level>
  <subject-area>
    <isced-f-code v6-value="031">0314</isced-f-code>
    <isced-clarification>Social and behavioural sciences</isced-clarification>
  </subject-area>
</recommended-language-skill>

Since the XSLT transformation won't exlude the isced-f-code and isced-clarification elements (there is no not(../../@not-yet-defined='true'), just not(../@not-yet-defined='true')), I think that the specification should forbid this sub-element in case recommended-language-skill is not defined, or the XSLT tranformation needs to be fixed.

And generally, I think that the specification should be clearer with the usage and interpretation of the not-yet-defined attribute and explain what exactly to expect when the data contradicts itself like in the example above (it says that it is not defined but the language is, in fact, defined...what an oxymoron!).

I suggest to add a note to the specification that in case an element contains the not-yet-defined attribute, client implementers MUST ignore its contents and not show anything to their users.

demilatof commented 12 months ago

Ok, so this is also allowed?

<recommended-language-skill not-yet-defined="true">
  <language>en</language>
  <cefr-level>B1</cefr-level>
  <subject-area>
    <isced-f-code v6-value="031">0314</isced-f-code>
    <isced-clarification>Social and behavioural sciences</isced-clarification>
  </subject-area>
</recommended-language-skill>

Since the XSLT transformation won't exlude the isced-f-code and isced-clarification elements (there is no not(../../@not-yet-defined='true'), just not(../@not-yet-defined='true')), I think that the specification should forbid this sub-element in case recommended-language-skill is not defined, or the XSLT tranformation needs to be fixed.

And generally, I think that the specification should be clearer with the usage and interpretation of the not-yet-defined attribute and explain what exactly to expect when the data contradicts itself like in the example above (it says that it is not defined but the language is, in fact, defined...what an oxymoron!).

I suggest to add a note to the specification that in case an element contains the not-yet-defined attribute, client implementers MUST ignore its contents and not show anything to their users.

I think the better solution is provided here with an updated XSLT: not-yet-defined, in my opinion, should involve all the sub-elements and the current XSLT has a bug. I think the error is that version 7 has been declared stable, whilst we are still exploring and testing it. In my opinion, it could be declared stable in January, hopefully.

janinamincer-daszkiewicz commented 12 months ago

I think the error is that version 7 has been declared stable, whilst we are still exploring and testing it. In my opinion, it could be declared stable in January, hopefully.

Generally I agree, however we would risk that providers would not start development waiting for the stable version. The old Catch-22 dillema.

janinamincer-daszkiewicz commented 12 months ago

not-yet-defined, in my opinion, should involve all the sub-elements

I also agree.

demilatof commented 12 months ago

Generally I agree, however we would risk that providers would not start development waiting for the stable version.

I don't know what options GitHub gives... But declaring it as a beta or "pre release" version could be enough to encourage the development.

janinamincer-daszkiewicz commented 10 months ago

https://github.com/erasmus-without-paper/ewp-specs-api-iias/compare/xslt-fix