Closed jiripetrzelka closed 10 months 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?
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.
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.
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')
, justnot(../@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.
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.
not-yet-defined, in my opinion, should involve all the sub-elements
I also agree.
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.
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?