Merge tests and fixes from stale PRs

[mielvds]

This PR attempts to integrate tests and fix from other PRs. Some of them are very old and are not mergeable anymore. However, most of these issues still persist and to not let this work go to waste, they are ported here:

Includes tests from or for issues:

• It is not always relevant to silently ignore unrecognized properties #50
• IRI expansion with missing @base does not conform to RFC 3986 #187
• Nested "@id" elements are not processed correctly in framing #149
• Fixed bugs in embed and remote frame context handling. #31
• Dates from schema.org are not compacted correctly. #59
• String xsd:double value crash toRdf() #202

Includes fix from or for:

• Proposed fix for issue #50 #51
• IRI expansion with missing @base does not conform to RFC 3986 #187
• Nested "@id" elements are not processed correctly in framing #149
• Fixed bugs in embed and remote frame context handling. #31
• Always try to add a default @type and @language #60 --> introduces regressions, so no included
• String xsd:double value crash toRdf() #202

[davidlehn]

General:

• I'm not sure this was the best approach to handle old issues and PRs. It's now very difficult to review, and difficult to handle one piece at a time.
• I don't think old issues should be closed until the issue is actually fixed, or at least merged into main.

Dropped "keys" / logging:

• The issue addressed by the on_key_dropped callback patch likely needs to be more involved. That was the path jsonld.js had to start. It then moved over to "safe mode" to handle that and many other situations that could cause problems when signing canonized output.
• If I had gotten to implementing a pyld "safe mode", it would likely have taken the simple path of throwing errors aligned with the js ones in all the needed places. More flexibility may only be needed for developer tools, which could be future work.
• Not sure what to suggest should be done here. This patch only handles one situation of many needed for a full "safe mode". An important one though.
• Is debug logging is the best default? Why not a no-op? The spec does allow dropped properties so arguably that's not something that needs debugging. If dropped properties are always an error is up for debate.
• On naming, I think "property" might be better than "key"? It aligns more with the spec. For the situation here, I think the js code is using a "invalid property" event / error code. But I understand the desire to match API naming with native data structures.

[mielvds]

Hi @davidlehn

General:

• I'm not sure this was the best approach to handle old issues and PRs. It's now very difficult to review, and difficult to handle one piece at a time.
• I don't think old issues should be closed until the issue is actually fixed, or at least merged into main.

I agree that this is not ideal and I admit I'm being pragmatic here. But this repo has too many open PR's and issues ranging from 2 to 9 years that could no longer be merged. So this is mostly housekeeping. Noted though: I'll keep the issues open until they are actually fixed and merged.

I selected and checked this set of issues carefully because they are about valid issues, include tests and partial fixes. All spec tests still pass like they did before. Except for the tests, all fixes were done in different commits, so I could make individual PR's is desired but that's more work for me :) All in all, I think the changes are not too big and reviewing should still be doable. Best is to start with checking the tests. I will add some more explanatory comments to help understand the original issue/fix.

Dropped "keys" / logging:

• The issue addressed by the on_key_dropped callback patch likely needs to be more involved. That was the path jsonld.js had to start. It then moved over to "safe mode" to handle that and many other situations that could cause problems when signing canonized output.

I agree but could we handle this is a new issue? I suggest we keep this change and possibly shake things up in a new release. I'm interested in how jsonld.js handles this.

• If I had gotten to implementing a pyld "safe mode", it would likely have taken the simple path of throwing errors aligned with the js ones in all the needed places. More flexibility may only be needed for developer tools, which could be future work.

This is a good approach. Can we place handlers (in line with on_key_dropped) where needed and implement a safe mode on top of that? This would also give developers more fine-grained control.

• Not sure what to suggest should be done here. This patch only handles one situation of many needed for a full "safe mode". An important one though.

I suggest a new issue to discuss a new iteration. I can open this and summarize what has been said so far.

• Is debug logging is the best default? Why not a no-op? The spec does allow dropped properties so arguably that's not something that needs debugging. If dropped properties are always an error is up for debate.

I actually agree, I just wanted to stay true to the original implementation. Introducing a logger is probably also something for a different PR. I'll patch this.

• On naming, I think "property" might be better than "key"? It aligns more with the spec. For the situation here, I think the js code is using a "invalid property" event / error code. But I understand the desire to match API naming with native data structures.

Hmm good point; I'll make the change. An explanation about 'key' in the docs should suffice