Remove timestamp examples from the 1.2 spec

[perlpunk]

https://yaml.org/spec/1.2.2/#24-tags
Example 2.22:

canonical: 2001-12-15T02:59:43.1Z
iso8601: 2001-12-14t21:59:43.10-05:00
spaced: 2001-12-14 21:59:43.10 -5
date: 2002-12-14

This should be removed, as none of the 1.2 schemas provides a timestamp tag anymore, and it might confuse people.
I saw it mentioned here: ruby/psych#262 (comment)

[ingydotnet]

Sounds good to me. I think we might be able to consider this errata in 1.2.2 and we could list it as such before publishing 1.2.3.

Thoughts?

[ronaldtse]

Thanks @perlpunk for clarifying this. In this case, is the correct way of handling a date/time a string?

[perlpunk]

See my answer in ruby/psych#262

[perlpunk]

Related: !!binary in Example 2.23 yaml/yaml#66

[ioggstream]

@perlpunk does this mean that binary and timestamp will just be triggered via explicit tagging?

[perlpunk]

@ioggstream binary and timestamp aren't official tags anymore at all in 1.2

[ioggstream]

@perlpunk so https://yaml.org/type/ does not apply as an extension to YAML 1.2 ?

[perlpunk]

@ioggstream I would say no, and if you have a look at the individual types under that link you will find "Working Draft 2005-01-18" on all of them, so they were actually never finalized at all.
I guess only @ingydotnet could tell you more about it.

[ingydotnet]

yaml.org/type is a sore spot that I've wanted to take down for a very long time.

Clark put these up as ideas in 2005, and they just stuck around even though we never agreed on them, iirc.

The 1.2.1 spec does reference that URL so we can't really take it down.

Perhaps the best solution now is to do something like we do for https://spec.yaml.io/main/spec/1.3.0/
saying that this is not currently recommended.

[ioggstream]

yaml.org/type is a sore spot that I've wanted to take down for a very long time.

where can I find a rationale for the takedown?

Clark put these up as ideas in 2005, and they just stuck around
even though we never agreed on them, iirc.

I think the reason is that they actually have real-life use cases

The 1.2.1 spec does reference that URL so we can't really take it down.
Ok.

[..] for https://spec.yaml.io/main/spec/1.3.0/ saying that this is not currently recommended.

Can you pls link me the section, since I wasn't able to find it? :P

Since yaml aims to be extensible, which extension mechanisms do you envision?

Thx++

[VladimirAlexiev]

I want to second that giving up on tags (especially datetime tags) may not be the best policy.
We want to standardize YAML-LD for use with Linked Data, and there xsd datatypes are important.

JSON has a poor and underspecified set of scalar (literal) types, so to reliably transfer scalars, it's best to use strings with another field signifying the tag (RDF datatype, called @type in JSON-LD).

I guess nothing stops us from defining XSD tags, eg something like this?

%TAG ! http://www.w3.org/2001/XMLSchema#

dc:date: !dateTime 2022-05-18T14:07:00

[gkellogg]

Deleted comment on YAML-LD, which was in the wrong repo. Reproduced in json-ld/yaml-ld#17 (comment).

[gkellogg]

I guess nothing stops us from defining XSD tags, eg something like this?

%TAG ! http://www.w3.org/2001/XMLSchema#

dc:date: !dateTime 2022-05-18T14:07:00

You would think that would be legal, given the definition of ns-global-tag-prefix. The Ruby Psych implementation based on libyaml does not accept the trailing # in the URI. yamlpp-parse-emit (based on Python, I believe) does not accept http://www.w3.org/2001/XMLSchema# complaining its a reserved directive, but is silenced if changing to tag:http://www.w3.org/2001/XMLSchema#. These certainly seem to be implementation bugs, but these are roadblocks to using what should be a natural namespace URI.

I'd expect the following to parse correctly:

%YAML 1.2
%TAG ! http://www.w3.org/2001/XMLSchema#
---
"@context":
  "@vocab": http://xmlns.com/foaf/0.1/
name: !string Gregg Kellogg
homepage: https://greggkellogg.net/
depiction: http://www.gravatar.com/avatar/42f948adff3afaa52249d963117af7c8
date: !date 2022-08-08

[perlpunk]

yamlpp-parse-emit is written in perl. And yes, that it accepts only tag:... or !... seems to be a bug. All the examples in the spec used that, so I never checked with the spec production.

[josephholsten]

Also relevant: 11ty/eleventy#413

[josephholsten]

👋 so here's my opinion (summarizing my comments at nodeca/js-yaml#477 (comment) & ruby/psych#262 (comment))

These other tickets are dealing with two cases:

• In 2019-03-22 20:18:42 +0100 interpreted as a string nodeca/js-yaml#477, one parser accepts 2019-03-13 20:18:42 +0000 while another does not
• In YAML.safe_load fails when a string contains a non-existent date ruby/psych#262, one parser raises an error on 2016-02-31

These are real world concerns of users interacting with very widely deployed parsers, and we're not going to take those working "YAML" documents out of the universe. We can take the examples out, but the parser implementations aren't going remove support without a better alternative for users.

But today the spec is way to ambiguous on its definition of timestamps. YAML 1.2 §10.1. Failsafe Schema doesn't actually provide any guidance about what to do with Example 2.22 Timestamps even though it's implied that it shouldn't need an explicit tag.

I'm inclined to say we should defer to RFC 3339 Date and Time on the Internet: Timestamps §5.6 Internet Date/Time Format, which covers the canonical, iso8601 and date examples, but I really don't know what to do about spaced: 2001-12-14 21:59:43.10 -5. If it were me, I'd say allowing space would go from RFC 3339's:

   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

to instead have:

   full-time       = partial-time [" "] time-offset
   date-time       = full-date ("T" / "t" / " ") full-time

But then we don't either allow 2019-03-13 20:18:42 +0000 (no colon) or 2001-12-14 21:59:43.10 -5 (not even remotely close to a time-offset).

I think that a well specified standard would require not just that the date-time match the ABNF, but that it be a valid date. If we deferred to RFC3339, it says:

    date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                             ; month/year

Which pretty clearly implies 2016-02-31 is not an RFC3339 date.

If we're throwing backward compatibility away, then referencing xmlschema dateTime with explicit tags is probably best, and we should add examples of its use instead of just removing timestamp examples.

Either way, the spec should hold the answers to these implementation tickets.