Hi Robert, On Thu, 2019-02-28 at 10:46 +0100, Robert Varga wrote: > On 28/02/2019 10:29, Rob Wilton (rwilton) wrote: > > Hi Robert, > > Hey Rob, > > > Isn't this just a limitation of JSON, in that the elements in an object are > > unordered (RFC 8259)? > > Yes, but I believe this is object semantics leaking to on-wire format: > while a JSON object is inherently unordered, when emitting object to the > wire, implementations can choose to order the pairs to make > receiver-side processing more efficient.
While this is possible in principle, it would require custom serializers/deserializers, at least in some programming languages. We tried to adhere to I-JSON [RFC 7494] that states: "The order of object members in an I-JSON message does not change the meaning of an I-JSON message." JSON has other issues when it comes to streaming, so perhaps it would be better to use another representation. Lada > > I wonder if it would be of value to communicate such assumptions out of > band, like separate content-types. In case of RFC7952 the following > hints would be useful: > - the document does not contain metadata (i.e. plain RFC7951) > - "@" occurs as a first element in an object or not at all > - "@foo" occurs immediately after "foo" or not at all > > This, of course, would be purely optional optimization... > > Regards, > Robert > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
