Hi, Richard. Welcome to the list, and I'm glad to hear you're actually implementing EDTF! Do you plan to make your implementation available, hopefully as FOSS?
I strongly agree with your idea of restricting valid characters in season qualifiers. In fact, offhand, it looks like the definition of qualifyingString should be changed; the ambiguity you mention could probably occur in other items based on qualifyingString. I'm not familiar with the C# "\w" regular expression character class, but it sounds like a reasonable way to define characters that can appear in qualifyingString.
From: Discussion of the Developing Date/Time Standards [[log in to unmask]] on behalf of Richard Tallent [[log in to unmask]]
Sent: Sunday, November 23, 2014 2:52 AM
To: [log in to unmask]
Subject: Season qualifier suggestion
I'm new to this list. I discovered the EDTF draft while researching extensions to ISO 8601 that would
be appropriate for genealogical source data (much of which can be uncertain), so I was very happy to
find your work here!
As an exercise to get my arms around it, I'm writing a reference implementation in C# for Levels 0, 1,
and portions of level 2 (which will be open source).
I realize it is a work in progress, but I would like to suggest that the valid characters for season
qualifier be limited further than just non-whitespace. The current definition theoretically includes ",",
"/", "]", and "}", which creates a potentially ambiguous situation for parsers.
For simplicity in my own implementation, I'm using the "\w" regular expression character class as
implemented under C#/.NET, which includes all Unicode letters and numbers and a few punctuation
symbols including underscores.