Thanks! By using Tie::Hash::MultiValueOrdered to create the initial hash, and then JSON::MultiValueOrdered to serialize it into JSON, the serialized output was in the right order.

(As you can tell from my commented-out line, I had a brain failure in my first attempt, and converted the ordered hash into a plain hashref, thus losing the original order. Once I realized that, I got it working.)

You may find a wrapper like this helpful:

sub h {
  tie my %hash, 'Tie::Hash::MultiValueOrdered';
  while (my ($k, $v) = splice @_, 0, 2) {
    $hash{$k} = $v;
  }
  \%hash;
}
[download]

That way you can build your data structure pretty naturally, just using h(...) for a hashref instead of {...}:

my $people = [
  h( name => "Alice", age => 21 ),
  h( name => "Bob", name => "Robert", age => 22 ),
];

print JSON::MultiValueOrdered->new(pretty=>1)->encode($people);
[download]

toby döt ink

>You may find a wrapper like this helpful

Ooh, that is nice. I'd even recommend adding it to the POD or the examples/ folder (or both) of the JSON-MultiValueOrdered distro.

JSON::MultiValueOrdered allows [...] duplicate keys like:

{
  "a": 1,
  "b": 2,
  "a": 3
}
[download]

... but the RFCs say that keys SHOULD be unique. On the other hand, the 2nd edition of ECMA-404 has seriously f...ed up the spec, while pretending to specify the same thing as the RFCs. See Re^4: Outputting JSON with sorted names/keys.

Short, if you want to play safe, don't assume any ordering on JSON objects, and make sure all keys of an object are unique. Or clearly document that you assume other rules.

Alexander

On the other hand... be liberal in what you accept. JSON::MultiValueOrdered was written with that principle in mind: to accept JSON documents that contain multiple values for keys or rely on key order. But it also allows them to be round-tripped.

Either way, it's a SHOULD and not a MUST. (Except in the I-JSON spec, which I think you missed out in your comparison of specs?) As long as you know what you're doing and have valid reasons to do so, you can forget SHOULDs. And if you're using JSON::MultiValueOrdered instead of JSON::PP or JSON::MaybeXS, it's probably for a reason.

Also, bear in mind that I started work on JSON::MultiValueOrdered more than seven years, so it predates all the JSON RFCs (except RFC 4627) and ECMA 404. The format description on json.org was also a lot more concise back then.

toby döt ink