Hi Nick On Wednesday, 10 August 2022 at 06:37:29 UTC+2 ni...@kurrawong.net wrote:
> If you have a strong request for what he might do - perhaps other format > conversions or benchmarking of RDFLib's implementation v. others - please > le me know on this mailing list ASAP. > Some things which need some attention which may be appropriate: - Parsers: we could really do with some other generated parsers (e.g. LARK). We have quite a few of known problems with the existing parsers, some of them are captured with xfails <https://github.com/RDFLib/rdflib/runs/7829635644?check_suite_focus=true#step:8:1611>, others with issues. Some are outright problems where we don't accept valid input but more are cases where we are too lax and accept input that we should not, these should ideally be fixed by having a fairly lax grammar that we then actually interpret differently based on laxness, but even just some basic lark parsers with max strictness next to existing parsers may be a good start, we could potentially mark them as _private at first until we are clear on how we want to expose them in the public interface. - JSON-LD testing: I recently overhauled all official W3C test suites except JSON-LD, this highlighted some misreporting in previous reports, and it also provides a much nicer EARL reporting which now runs on every test run and makes it easier to notice if the report output changes. This is however not being used for JSON-LD yet, but I also don't think we are running all JSON-LD tests. We need to improve JSON-LD, and we talked about that in previous issues, but before we do this I think we need to be very clear on our current JSON-LD compliance so we can quantify the effect of incorporating pyld. - JSON-LD support: We need better JSON-LD support, but this is also no small task, and probably the starting point is the test suite so this is somewhat stacked on the previous item. - SPARQL W3C testing: We are not running all tests from the W3C test for SPARQL, specifically we are skipping ServiceDescriptionTest and ProtocolTest <https://github.com/RDFLib/rdflib/blob/a39d1436e00affc3cba9e903b22700029d8e8163/test/utils/sparql_checker.py#L409-L412>, it would be nice to also run them. - SNYK-PYTHON-RDFLIB-1324490 <https://security.snyk.io/vuln/SNYK-PYTHON-RDFLIB-1324490> vulnerability: we have this issue (#1844 <https://github.com/RDFLib/rdflib/issues/1844>) that is a bit of a impediment to people using RDFLib, may be worth looking at it, we had a PR (linked in the issue itself), but the PR is a bit hit and miss, it can be salvaged but it needs quite a bit of work and the problem of URI resolution is quite broad and should possibly cover things like resolving to filesystem also so we can use it instead of URIMapper in our test suite <https://github.com/RDFLib/rdflib/blob/a39d1436e00affc3cba9e903b22700029d8e8163/test/utils/iri.py#L103> also. - Performance testing: It would be nice to have some automated performance testing that we can run on every PR so we can quantify the performance impact PRs have. Regards Iwan Aucamp -- http://github.com/RDFLib --- You received this message because you are subscribed to the Google Groups "rdflib-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to rdflib-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/505a1021-557d-4613-8adf-cdb9c2201d4an%40googlegroups.com.
