This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27171 - Outputting JSON, serializing sequences
Summary: Outputting JSON, serializing sequences
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Serialization 3.1 (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-25 14:52 UTC by Christian Gruen
Modified: 2014-10-28 19:02 UTC (History)
1 user (show)

See Also:


Attachments

Description Christian Gruen 2014-10-25 14:52:54 UTC
I know I should have replied earlier to Michael's requests on serializing JSON (#26784), but I think that one issue is worth being discussed a bit more:

If sequences with zero items or more than one item are to be output on top level, I would recommend not to output them as 'null' or as array:

* To me, serialization has always been a non-blocking operation. If we don't know in advance if a query will yield more than one item, and if we treat sequences as arrays, we would from now on need to cache the first item before we know if it needs to be prefixed with a square bracket.

* In my perception, all other output methods handle sequences differently. Think of the XML output method: multiple nodes will simply be appended to each other, and the result won't be wrapped by an additional root element.

* Similarly, if a query does not yield any result, I would expect it not to return any output at all, as is the case with the other output methods.

If sequences occur on a deeper level, an error may be more appropriate. This way, parsing and serializing JSON will be more bidirectional. See the following query as example:

  map { 'A': ('B','C') }

If the value of the map object would now be serialized as array, and if it was parsed via fn:parse-json, we would get a different result.
Comment 1 Christian Gruen 2014-10-25 14:59:33 UTC
A little addition: if the serialization of sequences is changed, the item-separator parameter could be defined the same way as for the other output methods.
Comment 2 Jonathan Robie 2014-10-28 18:56:26 UTC
(In reply to Christian Gruen from comment #0)
> I know I should have replied earlier to Michael's requests on serializing
> JSON (#26784), but I think that one issue is worth being discussed a bit
> more:
> 
> If sequences with zero items or more than one item are to be output on top
> level, I would recommend not to output them as 'null' or as array:

We have only one way to specify a JSON null, and that's an empty sequence. So I think serializing as 'null' is appropriate here.

I agree that we should not serialize a sequence of length > 1 as an array. The WG agreed to that yesterday.
Comment 3 Christian Gruen 2014-10-28 19:02:58 UTC
> We have only one way to specify a JSON null, and that's an empty sequence.
> So I think serializing as 'null' is appropriate here.

After some thoughts, I also came to the conclusion that serializing an empty sequence as 'null' also makes sense on top level (otherwise, serialization and parsing would not be bidirectional anymore).

> I agree that we should not serialize a sequence of length > 1 as an array. The WG agreed to that yesterday.

Thanks for pointing this out; I'm closing this issue.