Array of Forms ordering

[farshidtz]

The spec is vague on the ordering of forms Arrays. The context sets "@container": "@set" which indicates that the array is "unordered set of data", but this is hard to know without looking at the context and being able to understand it.

Why is it unordered? Isn't it better to set "@container": "@list" and maintain the order? Otherwise a triple-store may return the array in a different order. This would disallow picking the right form by index and requires a lookup every time (see #877). It also makes canonicalization and implementation testing much harder.

From https://w3c.github.io/wot-thing-description/#canonicalization-serialization-json

In order to support canonicalization, implementations of TD Processors MUST preserve the order of elements in all arrays.

From https://w3c.github.io/wot-thing-description/#preliminary-definitions

Though this definition does not prevent Objects to include multiple name-value pairs with the same name, they are generally not considered in this specification. An Object whose elements only have numbers as names is called an Array. Similarly, an Object whose elements only have Terms (that do not belong to any Vocabulary) as names is called a Map. All names appearing in some name-value pair in a Map are assumed to be unique within the scope of the Map.

From https://w3c.github.io/wot-thing-description/#sec-td-serialization

Every complex type of the TD Information Model (i.e., Arrays, Maps, and Class instances) maps to a structured JSON type (array and object), as per the rules listed below:

• A value of type Array MUST be serialized as JSON array, with each value of the name-value pairs as element of the JSON array ordered by the numeric name of the pair.
• A value of type Map MUST be serialized as JSON object, with each name-value pair as member of the JSON object.
• A Class instance MUST be serialized as JSON object, following the detailed rules given individually in § 6.3 Information Model Serialization.

[AndreaCimminoArriaga]

As an aside comment, when a TD containing an array is translated into RDF such array becomes an object property which cardinality is not known beforehand (it should be specified in the ontology code and validated with a shacl shape). In addition, since it is translated into an object property the different resources in the range of such property are unsorted. As a result, if an array is translated into RDF and back the second array will contain the same elements than the former but not necessarily in the same order.

On the other hand, if the arrays must retain their order then they should be translated as rdfs:List instead of object properties. Otherwise there is no way to know their order in the translation back from RDF to JSON-LD framed.

[relu91]

I think that forms field was described as a @set because in the early days forms were thought to be as equivalent one to another (e.g., applications should just care about affordances not how they are invoked). Instead, now we have different use cases where applications actually look inside the forms containers to choose the desired form. We even have added this ability to the Scripting API document.

So to wrap up in my opinion it makes sense to maintain the order and change from @set to @list.

[AndreaCimminoArriaga]

Ok, however if the order is maintained, and thus marked as @list, the @context of the JSON-LD framed must be modified accordingly to translate the arrays into rdfs:List otherwise there is no way to perform a correct round-trip

[sebastiankb]

@vcharpenay would be this ok to change @set to @list ?

[mmccool]

We discussed this further in discovery while trying to wrap up #1981 and we really really really want arrays to be ordered. Also, it's a requirement of TD processors in order to support canonicalization now, but if arrays are treated as sets any RDF processor will break canonicalization (and therefore signing, etc.)

So... PLEASE change @set to @list for all arrays. It's not a perfect solution but better than all the alternatives as far as I can see.

[mmccool]

Note this should apply to ALL arrays, not just Forms. This includes things like the "security" field, etc. Basically, don't use @set.

[egekorkan]

Closing this as part of canonicalization issues. They will be reconsidered in 2.0 by searching for the label