W3C home > Mailing lists > Public > public-linked-json@w3.org > April 2012

Framing test cases

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Tue, 3 Apr 2012 12:56:24 -0400
To: "public-linked-json@w3.org JSON" <public-linked-json@w3.org>
Message-ID: <AFAD4503-43B1-40DF-AD94-271F9DF11034@greggkellogg.net>
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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:33 UTC