Including `alignment` in Achievement, ResultDescription, Result, and RubricCriterionLevel makes the spec hard to implement

[amiller-ims]

As an (reference) implementer of both an issuer and a verifier of achievements, I find it harder than necessary to implement alignments at all those places. I really only need alignments in the Achievement object. Removing alignment from ResultDescription, Result, and RubricCriterionLevel would make the spec easier to implement for both issuers and verifiers.

If there are use cases that require alignment of a result, then I suggest removing alignment from the Result object and keep alignment in the ResultDescription and RubricCriterionLevel. Having alignment in both ResultDescription and Result is confusing. If the alignment in ResultDescription and Result conflict, it is unclear how to resolve the conflict.

[ottonomy]

I think the use case for having it in Result is to enable issuers to claim a particular result against a particular thing that is not described in a ResultDescription. (Note that result.resultDescription is not a required property). In the OB 2.0 landscape where there was only one alignment property, alignment also could mean many different things, but consumers often had to make limiting assumptions to make their work actionable, such as saying that "any badge that aligns to a skill URL that I'm looking for is claiming that the learner has mastered this skill in a binary sense", even though that is nowhere close to the only possibility for why an issuer might publish an alignment in a badge. I think the use case was to give issuers more expressive capability to say just how much a learner had actually completed the thing in the alignment instead of having it all-or-nothing as we were forced to assume under OB 2.0.

Indeed this is one of the things that comes up when we were heavily stacked with issuer-side use cases and not very populated with consumer-side representatives. There's a lot of possible variation around what these different alignments are supposed to mean. When there is a lot of variation on the issuer side, that means a lot of expense to exhaustively support all options on the consumer side. I recommend consumers just ignore all cases of alignment other than Achievement.alignment until it is clear how issuers are using them.

My consumer/verifier recommendations:

• Implement something simple before trying to dig into complicated things, test the market value of the simple processing method before continuing
• What choices issuers make will in part be driven by how their badges are interpreted by well-placed consumers, so early-to-market consumers might have a lot of influence over how these properties are used.

Can your implementation challenge be avoided by ignoring alignments beyond what you initially build the ability to process?

[xaviaracil]

• Leave the fields as is for now.
• Get feedback of the use of alignment.
• Make changes in future versions.

[andyfmiller]

@ottonomy I agree with everything you wrote.

Can your implementation challenge be avoided by ignoring alignments beyond what you initially build the ability to process?

Yes. and that is what I plan on doing.

I recommend consumers just ignore all cases of alignment other than Achievement.alignment until it is clear how issuers are using them.

That is a very practical approach given where the spec is in the development process. 1EdTech's normal process (Section 5.2.2 Candidate Final Draft) is to:

1. Require as least two independent, interoperable implementations of the Candidate Final Draft spec.
2. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Candidate Final only if those options or features are removed.

That is similar to what you are proposing, just at an earlier stage.