Framing test cases

Some issues regarding framing test results, dependent on resolution of default value issue and how to specify graph flattening before framing (relating to default ordering of otherwise unordered values):

frame-0005 among other things, checks that a property is created if it doesn't exist in the input, but has an object in the frame.

Frame: {..., "ex:null": {}}

The current result is, null: {...,"ex:null": null}

Of course, this goes away when compacting, I believe it should result in the following: {..., "ex:null": []}. To return this requires also adding {"ex:null": {"@container": "@set"}. I propose we modify the test accordingly.

frame-0007 contains a type with two values: {...,"@type": ["ex:Library", "ex:Building"], ...} This brings up the issue of value ordering. Of course, these are interpreted as unordered, but when doing value testing the fact that multiple values expressed in a different order will cause the test to fail causes a problem.

My implementation implements framing by flattening the input using a transformation through RDF. The transformation from RDF back to JSON-LD orders the input, and thus my version yields {"@type": ["ex:Building", "ex:Library"]}. Whether it's done here or not, we should consider specifying how values are ordered, at least for the purpose of passing tests. Otherwise, I'll implement a test comparison that does unordered array checking, unless the result is coerced to @list, but this is a real pain.

Alternatively, we could create a different flattening algorithm that preserved original document order, but it creates some corner-cases such as how to merge two objects having the same @id.

frame-0008 has a similar object ordering issue, in this case for ex:mixed results.

frame-0009 has the default value issue for ex:p5.

frame-0012 has an ordering issue on the relative order object subjects based on @id

Gregg

Received on Tuesday, 3 April 2012 16:57:29 UTC