Project

Profile

Help

Bug #4826

Indentation inconsistency when serializing JSON

Added by Jerry Jackson 12 months ago. Updated 7 months ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
Serialization
Sprint/Milestone:
-
Start date:
2020-11-16
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:
Platforms:

Description

I have this code:

...
<xsl:for-each select="1 to 6">
   <xsl:variable name="fields" select="$block/fields/ES_KALEIDOSCOPEFIELD[@fieldNumber = current()]"/>
   <xsl:sequence
      select="map{'field' || current(): map{
         'field': mgx:join($fields//@value),
         'color': mgx:join($fields//@htmlvalue!concat('#', .))
      }}"
   />
</xsl:for-each>

<xsl:function name="mgx:join" as="xs:string?">
   <xsl:param name="values" as="xs:string*"/>
   <xsl:sequence select="if(empty($values)) then () else $values => string-join(' ')"/>
</xsl:function>

When serializing this to JSON, it seems there is a difference in indentation if one of the values is null instead of a string:

"field3": { 
"color": "#FF8080",
"field": "Purchase" },
"field4": {
"color": null,
"field": null
},
"field5": { 
"color": "#FFC080",
"field": "Sport - other" },

Not a big deal of course, but it looks a bit off. I think the most common way of indenting a JSON object is to put the ending curly bracket on a separate line (the way field4 is displayed).

History

#1 Updated by Michael Kay 11 months ago

  • Category set to Serialization
  • Assignee set to Michael Kay
  • Applies to branch 10, trunk added

Thanks, yes we're aware that the JSON indenter isn't perfect (and in a sense, it never will be).

We're trying to identify maps and arrays that are sufficiently small to put on a single line. This is probably more important for arrays, e.g. [1, 5, 6] than for maps, but even with maps I think it's good to output {"x": 3, "y": 4} on a single line if we can. But there seem to be at least two things wrong with the logic: (a) the presence of a "null" is disqualifying the map as a one-liner, and (b) having decided the map will fit on one line, we're indenting it anyway.

This of course isn't a conformance issue, but it's still nice to get it right.

#2 Updated by Michael Kay 11 months ago

  • Status changed from New to Resolved
  • Fix Committed on Branch 10, trunk added

#3 Updated by Michael Kay 11 months ago

  • Status changed from Resolved to In Progress

The patch led to a regression in test accumulator-068 - the JSON serialization of the value includes a space character which shouldn't be there.

#4 Updated by Michael Kay 11 months ago

  • Status changed from In Progress to Resolved

The regression is now fixed.

#5 Updated by O'Neil Delpratt 7 months ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.5 added

Bug fix applied to Saxon 10.5 maintenance release.

Please register to edit this issue

Also available in: Atom PDF