Closed steve-bate closed 1 month ago
I'm not sure that the compactArrays option existed when AS2 was specified.
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
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?
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.
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.
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
Please Indicate One:
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 standard JSON-LD Compaction Algorithm is configurable and has an option
compactArrays
that defaults totrue
. 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 asfalse
), 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?