String-literal conneg tests

[michielbdejong]

When I originally started exploring the test for conneg, it was easy to check strings against strings. Once that worked, I added the tests for asTriples. I think we will never have good maintainable string-based conneg tests, so maybe we should just use the as triples tests only? So:

• take a string in content type 1
• upload it
• retrieve it, accepting content type 2
• rather than looking at the response body string, just parse it into rdflib
• compare the resulting set of triples to the set triples in the document that was uploaded.

[edwardsph]

I agree but I would still do a simple first test to establish you got back something in the correct format then the second test only compares the graph. Note that this is where you need the set based comparison I used elsewhere not equality since you may also get server generated triples.

[bourgeoa]

Don't you think parsing is enough. If parsing fail then the document is wrong.

[ylebre]

I agree that the best way is to parse the result into RDFlib. Depending on the situation we could opt to just validate that the expected triples are in the result, ignoring any other triples that might be in there?

[edwardsph]

If you convert to an array of triples you can use the matcher: includesAllMembers to check the result includes the expected. By the way, this also solves the problem that JSON-LD has alternative forms and you can't predict which the server will give you so string comparison, or even JSON object matching will fail.

On Wed, 10 Feb 2021, 13:20 Yvo Brevoort, notifications@github.com wrote:

I agree that the best way is to parse the result into RDFlib. Depending on the situation we could opt to just validate that the expected triples are in the result, ignoring any other triples that might be in there?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/michielbdejong/community-server/issues/10#issuecomment-776700674, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACICDC6NTG3RBRPPA3AOI63S6KBY5ANCNFSM4XMW245A .

-- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged, confidential and/or proprietary information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), please do not disseminate, distribute, print or copy this e-mail, or any attachment thereto. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the email.

[bourgeoa]

If you convert to an array of triples

The array of triples will still need to be normalised for blank-nodes.

[michielbdejong]

I commented out the tests so they don't show up as skipped. We could remove them altogether when we're certain we don't want them back.

[bourgeoa]

@michielbdejong

compare the resulting set of triples to the set triples in the document that was uploaded.

To make the comparison easier to understand and follow, I propose to make :

• the triples comparison on sorted array of N-triples : store.toNT(),split('\n').sort()
• to normalize blank nodes with the following RegExp : ArrayOfNTriples.map(item => item.replace(RegExp((<\_:[\w-]*>)|(\b\_:[\w-]*), gm), '<_:b0>') replace with <_:b0> all words (containing letters, digits, and -), that begin with <_: or \:

I made the test on NSS and CSS. Or do you prefer to keep the tests as they are ?