Project

Profile

Help

Feature #4989

Make adaptive output method serialize dateTimeStamp as xs:dateTimeStamp instead of xs:dateTime

Added by Martin Honnen about 1 month ago. Updated 8 days ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2021-05-12
Due date:
% Done:

0%

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

Description

Saxon JS 2.2 serializes an xs:dateTimeStamp with the adaptive output method as xs:dateTimeStamp(...) while Saxon Java (tested with HE 10.5) outputs xs:dateTime, whether the value is of type xs:dateTime or of the subtype xs:dateTimeStamp.

It seems Saxon Java could output e.g. xs:dateTimeStamp(...) for the result of e.g. current-dateTime() or other values which have a timezone and are xs:dateTimeStamps.

Currently serializeAtomicValue in the AdaptiveEmitter treats all xs:dateTime the same as other types and simply does return value.getPrimitiveType().getDisplayName() + "(\"" + value.getStringValue() + "\")";

If

            case StandardNames.XS_DATE_TIME:
                return value.getItemType().getDisplayName() + "(\"" + value.getStringValue() + "\")";

were used the output would be adapted to the actual type (i.e. xs:dateTime or xs:dateTimeStamp), I think.

History

#1 Updated by Martin Honnen about 1 month ago

It seems the spec talks about primitive types to be used which xs:dateTime is but not xs:dateTimeInstance.

There is even a test case https://github.com/qt4cg/qt4tests/blob/master/ser/method-adaptive.xml#L695 in the XQuery test suite requiring xs:dateTimeStamp('2011-07-28T12:34:56-08:00') to be serialized as xs:dateTime("2011-07-28T12:34:56-08:00") and an old bug entry https://www.w3.org/Bugs/Public/show_bug.cgi?id=29913 that discussed that to be in line with the fine print of the spec.

Based on that my "feature" request seems wrong.

Or only raises the question why Saxon JS 2 does give xs:dateTimeStamp ("2011-07-28T12:34:56-08:00") for

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  version="3.0"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  exclude-result-prefixes="#all"
  expand-text="yes">

  <xsl:output method="adaptive"/>

  <xsl:template name="xsl:initial-template">
    <xsl:sequence select="xs:dateTimeStamp('2011-07-28T12:34:56-08:00')"/>
  </xsl:template>

</xsl:stylesheet>

#2 Updated by Michael Kay 9 days ago

Although the serialization spec is explicit

An atomic value of any other type is serialized using the syntax of a constructor function: xs:TYPE("VAL") where TYPE is the name of the primitive type,

I'm not sure that it really intended to be that prescriptive. The introduction says:

The Adaptive output method serializes the instance of the data model into a human readable form for the purposes of debugging query results.

And I'm tempted to give priority to that statement of intended purpose, and accept the suggestion.

However, it would seem perverse to output a specific non-primitive type for xs:dateTimeStamp and not to do the same for types derived from xs:string (such as xs:NCName), and that opens the question of whether xs:anyURI and xs:untypedAtomic should be output any differently from xs:string (the current spec is clear that they should not). This is starting to suggest we need an extra serialization parameter to control this. But is the requirement important enough to justify it?

#3 Updated by Martin Honnen 8 days ago

Michael Kay wrote:

Although the serialization spec is explicit

An atomic value of any other type is serialized using the syntax of a constructor function: xs:TYPE("VAL") where TYPE is the name of the primitive type,

I'm not sure that it really intended to be that prescriptive. The introduction says:

The Adaptive output method serializes the instance of the data model into a human readable form for the purposes of debugging query results.

And I'm tempted to give priority to that statement of intended purpose, and accept the suggestion.

However, it would seem perverse to output a specific non-primitive type for xs:dateTimeStamp and not to do the same for types derived from xs:string (such as xs:NCName), and that opens the question of whether xs:anyURI and xs:untypedAtomic should be output any differently from xs:string (the current spec is clear that they should not). This is starting to suggest we need an extra serialization parameter to control this. But is the requirement important enough to justify it?

Probably not, I just wondered about the difference between Saxon Java and Saxon JS 2 and someone on Slack also thought that the use xs:dateTimeStamp is more informative than xs:dateTime if the former is the actual type.

Please register to edit this issue

Also available in: Atom PDF