Normative requirement "MUST omit empty arrays" is unsound and contradictory

Problem

branching from #656 i was made aware of the following language in AS2-Core Section 2, "Serialization"

When serialized, absent properties are represented by either (a) setting the property value to null, or (b) by omitting the property declaration altogether at the option of the publisher. These representations are semantically equivalent. If a property has an array value, the absence of any items in that array MUST be represented by omitting the property entirely or by setting the value to null. The appropriate interpretation of an omitted or explicitly null value is that no value has been assigned as opposed to the view that the given value is empty or nil.

The rest of the paragraph is fine, because null and omitted properties are indeed semantically equivalent. ("If you don't have anything to say, then don't say anything.")

However, the highlighted bit about empty arrays is not only out of place, but it is also unsound guidance. An empty array is saying something: that the value is an empty set or an empty list (depending on how the property is defined).

Furthermore, it is contradictory with how some properties are defined in the normative activitystreams context, at least for orderedItems (which is defined as @container: @list). This definition means that orderedItems is, well... an ordered list. An empty list is semantically distinct from an empty set, and both are semantically distinct from null/omission. This makes the requirement unsatisfiable as it conflicts with another requirement, that AS2 documents MUST be consistent with what would be produced by compaction.

Note for example the following OrderedCollection:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "OrderedCollection",
  "orderedItems": []
}

When compacted, it produces itself.

When expanded, it produces this:

[
  {
    "https://www.w3.org/ns/activitystreams#items": [
      {
        "@list": []
      }
    ],
    "@type": [
      "https://www.w3.org/ns/activitystreams#OrderedCollection"
    ]
  }
]

Note the {"@list": []} structure that is preserved, instead of simply [] to indicate an empty @set. An empty list is represented in plaintext RDF representations (Turtles, N-Triples, N-Quads, TriG) as rdf:nil, which is defined as equivalent to the empty list (in other words, the rdf:List whose rdf:first element is rdf:nil and whose rdf:rest of the list is also rdf:nil). Empty sets don't survive the round-trip to RDF, but are still potentially significant in the JSON document, e.g. for fulfilling schematic constraints (where some property is expected to always have an array value of zero or more items).

Solution

Erratum, although this technically qualifies as a Class 3 change since it affects compliance (without adding new features). However, as noted above, it is actually impossible to comply fully with AS2-Core because of two conflicting requirements.

Error description

Activity Streams 2.0 Core, Section 2 "Serialization", reads in part: "If a property has an array value, the absence of any items in that array MUST be represented by omitting the property entirely or by setting the value to null." This requirement prevents making assertions that the value of a property is an empty set or an empty list, which are semantically distinct from null values or omitted properties (and also semantically distinct from each other). Also, this requirement conflicts with another requirement in Section 2.1, which reads: "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 Compaction Algorithm using, at least, the normative JSON-LD context definition".

Candidate correction

Remove the quoted requirement from Section 2, allowing arrays with no items. Potentially add a non-normative note explaining the difference between an empty set and an empty list.

Start with Activity Streams 2.0 Core Section 2, “Serialization,” and compare the empty-array requirement with Section 2.1 and the normative JSON-LD context. Review the OrderedCollection example and its compaction and expansion behavior. Done means the conflicting requirement is resolved in the specification, with any needed explanatory note and an agreed erratum.