-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OB3: Conflict between Data Model and Json Schema! #553
Comments
My understanding is that the cardinality of So, if my understanding is correct, the current json schema is valid. |
I think @Oran-Dan is right. For example,
I think that applies to all extensible types such a AlignmentTargetType. Values can only match the underlying type or the extension pattern, not both. Since the extension pattern is not ever part of the underlying type, |
Agree that My point was that either I will update the schemas to have |
Thanks for both your quick replies! I'm a back-end developer trying to translate the Json Schema into Rust. The aim is to develop software which enables users to issue there own OpenBadges (to for example their students). We used the Typify library (https://crates.io/crates/typify/0.0.14) to convert the Json Schema to Rust code and it does so pretty well. But due to the cardinality specified, it had translated these types not to enums but to structs, which complicates things a bit. With enums the logical implications (OneOf) are obvious and require no extra coding. With structs however, it's a hassle to implement the rules as structs support a much wider, less straightforward, use. I'm fairly certain the same goes for many other coding languages to which this Json Schema will be translated if others want to develop software to support OpenBadges v3. Finally, I understand that it makes no difference to human logic wether it is AnyOf or OneOf, since it can't be both at the same time anyway. But hopefully the context provided has clarified that, to my opinion, it does matter when translating this to code. Although, I must admit I don't fully understand your explanations Xavi, hopefully you can clarify. Is this a correct understanding of the Data Model and the Json Schema? Thanks for your time and explanations. |
Thanks @Oran-Dan for the clarification. Your understanding is correct, On the other hand, instances 3, 4 and 5 in your initial comment are mandatory fields (so their cardinality is None of the instances in your comment are collections that can hold multiple values. We do have a data modeling system that autogenerates the JSON schemas. I'll make the proper changes to that system and publish the updated schemas. |
Thanks a lot! |
Data Model specifies [0..1] or [1] options, Json Schema says AnyOf, which translates to [1..*] (all of the actual instances would be [1..2])
Conflict occurs in five occasions, all five conflicts are of the same type.
To me, it seems that both the data model and the Json Schema are wrong.
I think the Json Schema should use the word "OneOf" in all instances.
Also, the data model should say [1] in all instances.
Data Model:
achievementType [AchievementType Enumeration] The type of achievement. This is an extensible vocabulary. [0..1]
Json Schema:
Exact same situation
Data Model:
identifierType [IdentifierTypeEnum Enumeration] The identifier type. [1]
Json Schema:
Same situation as 3
Same as 3 and 4
If the proposed solution is agreed upon, I can open a pull request for it as well.
The text was updated successfully, but these errors were encountered: