Are non-default standard JSON-LD Compaction configurations conformant?

[steve-bate]

Please Indicate One:

• [ ] Editorial
• [X] Question
• [ ] Feedback
• [ ] Blocking Issue
• [ ] Non-Blocking Issue

Please Describe the Issue:

I have a question about AS2 JSON-LD array compaction requirements in the context of developing an ActivityPub test suite. The Activity Streams 2.0 spec says:

The serialized JSON form of an Activity Streams 2.0 document must be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm using, at least, the normative JSON-LD @context definition ...

The standard JSON-LD Compaction Algorithm is configurable and has an option compactArrays that defaults to true. With the default compaction configuration, single-element arrays are replaced with the array element. If an implementation uses the standard Compaction Algorithm with non-default options (e.g., compactArrays configured as false), is that conformant? In other words, does a test suite (or an AP/AS2 implementation) need to accept the results of all permutations of the compaction-related configuration parameters?

[nightpool]

I'm not sure that the compactArrays option existed when AS2 was specified.

[steve-bate]

I'm not sure that the compactArrays option existed when AS2 was specified.

It is described in the version of the JSON-LD API document included in the normative AS2 references. https://www.w3.org/TR/2014/REC-json-ld-api-20140116/#widl-JsonLdOptions-compactArrays

[bumblefudge]

commenting for updates, curious myself about this nuance of JSON-LD in the wild. maybe @timothee-haudebourg might have some insights on how devs and libraries actually use (or shouldn't use) compactArrays, as he's done some conformance testing on commonly-used LD libraries?

[evanp]

So, this may come up for properties such as:

"to": ["https://social.example/users/bob"]

I'd says that compliant processors SHOULD be able to handle both that format and:

"to": "https://social.example/users/bob"

One area in which a processor may get tripped up is with the items and orderedItems properties. I don't think this is "proper" AS2, but I'm not sure.

"items": "https://social.example/note/35"

This structure is much more likely to be understood by simpler processors:

"items": ["https://social.example/note/35"]

I think Postel's rule would advise against the first formulation -- most JSON-only processors are going to choke on a non-array value in items. However, if you're working on strict compliance, that might be something that is required.

[steve-bate]

Based on experimentation in JSON-LD Playground it appears that turning off the compactArrays for compaction may also result in other undesirable side effects. The following document:

{
  "@context": ["https://www.w3.org/ns/activitystreams"],
  "type": "Note",
  "id": "https://postparty.example/p/2415",
  "to": "https://server.example/user/berryfan",
  "content": "I like strawberries!"
}

will compact to the following document using the normative context and setting compactArrays to false.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "@graph": [
    {
      "id": "https://postparty.example/p/2415",
      "type": "Note",
      "content": [
        "I like strawberries!"
      ],
      "to": [
        "https://server.example/user/berryfan"
      ]
    }
  ]
}

The JSON-LD processing algorithms are complex enough that I cannot determine if not compacting the graph is standard behavior or something specific to the library used to implement JSON-LD Playground. It seems like the safest path is to explicitly state that the documents are compacted with the normative context, the standard algorithm, and standard default compaction options.

[nightpool]

I agree with this and i think it's non-disruptive enough to specify as an errata but we should also make the items: {"@container": "@set"} change that trwnh advocates for here: https://github.com/w3c/activitystreams/issues/537