Feature #4989
closed
Make adaptive output method serialize dateTimeStamp as xs:dateTimeStamp instead of xs:dateTime
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:dateTimeStamp
s.
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.
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>
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?
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.
- Status changed from New to Closed
I'm not motivated to keep this on the list any longer, I don't think the need is strong enough to require action.
Please register to edit this issue
Also available in: Atom
PDF