Syd - again, thanks for the comments. From: Syd Bauman > 201 > --- > * "The characters '?' and '~' apply either to the entire portion of > the string to their left, unless": but they don't apply to the > entire *string* to their left, only to the *date*, *time*, or > *dateTime*, right? (See 103 and 205.) I changed "string" to "date-string" > * "another component of ... of that component.": there are no > examples of this, which makes me nervous. Does it mean that the "~" > in (2011)-06-04~ only applies to the "-06-04" part? A better example would be '(2011)?-06-04~' in which the "~" only applies to the "-06-04" part. However, '(2011)-06-04~' would be interpreted to mean that "~" only applies to the "-06-04" part, but it would be better expressed as '2011-(06-04)~'. I've added examples for this. > * "'?' and '~' apply to a year, month, day, year-month, month-day, or > year-month-day. ...": why on earth would they not be applicable to > the hour, minute, second, hour-minute, minute-second, or > hour-minute-second? Because nobody expressed a need. > 2041 > ---- > What is the difference between masked precision and unspecified? I have added a note: In feature "Masked Precision" '196x' is said to have "decade precision". In contrast, '196u' has year precision. Both represent a year during the 1960s, but for 196x the year isn't given because it is known only with decade precision. For 196u the year isn't given for reasons that are not specified but there is some expectation (though no guarantee) that the year may be supplied later; for 196x there is no such expectation. > It may be useful to express these as equivalents of some sort: > 196x = 1960-01-01/1969-12-31 > or whatever. No, 196x is not intended to represent an entire decade, but rather a single year (with decade precision). > 207 > --- > This seems a bit silly to me. The "yyyy-mm-dd" pattern makes no sense > in some other calendars. The need was expressed to be able to specify a calendar, and so this is the way to do it. How this feature will be used is up to those who requested the feature to figure out, this has not been developed whatsoever beyond this simple ability to specify a calendar name, and it may never be. And if it is, only a date of the form yyyy-mm-dd which is meaningful in some other calendar would be compatible with this spec (and that assumes that some vocabular for calendar names is recognized) and to accommodate dates of a different form, the spec will need to be enhanced. This is all left for future work. > 208 > --- > As I've said before, I think 104 should be moved here to L2, or, better > by far, both 104 and 208 should be dropped. A reasonable use case for > years > 4 digits is *extremely* rare, and is completely impossible in > bibliography. We want astronomers to be able to use this spec too. > 209 > --- > This, along with 207 and most of the possible future features, should > probably be avoided. But again this is a requested feature. It is anticipated that communities will develop vocabularies for seasonal profiles and these could be specified in profiles. > I presume that whitespace is not permitted in any of these notations. Right, I added a note.