Gelijktrekken definitie, naam, waardeverzameling, formaat en uitwisselingsmasker van datum(-tijd) binnen het stelsel.

Bovengenoemde stelseldefinities voor datum en tijd zijn verwerkt in het nieuwe stuf0302.xsd schema (in ontwikkeling).

Met dank aan Michelle voor het opstellen van de niet geheel triviale reguliere patronen voor onvolledige datum en tijd-datum.

we waren vergeten om de namespace aan te passen naar 0302. Meteen heb ik in de namespace ook www.egem.nl vervangen door www.kinggemeenten.nl

De verbeterde versie is als bijlage bijgevoegd (de extensie moet van 'txt' hernoemt worden naar 'xsd').

Het RFC staat hier nog een beetje vrijblijvend geformuleerd. Volgens mij heeft StUF zich verbonden om de afspraken in het kader van de Gemeenschappelijke Afspraken Berichten (GAB), voorheen bekend als Project Utrecht, zo snel mogelijk te implementeren.

Wat dat bijvoorbeeld voor datum/tijd betekent staat helder in de vastgestelde specificaties die vallen onder "pas toe of leg uit". Volgens mij is hier dus geen discussie meer over nodig en is dit een kwestie van implementeren:

http://www.noraonline.nl/wiki/Gemeenschappelijke_Afspraken_Berichten

Inmiddels is bovenstaand RFC0121 uitgewerkt, zie stuf0302.pdf en stuf0302.xsd in de vergaderstukken van de bijeenkomst van de StUF Expertgroep morgen. Echter vandaag heeft er voortschrijdend inzicht plaatsgevonden.

In de hier bovengenoemde stuf0302.xsd kom ik namelijk de volgende definities tegen:

<complexType name="Datum-e">

                        <simpleContent>

                                    <extension base="date">

                                                <attribute ref="StUF:noValue"/>

                                    </extension>

                        </simpleContent>

            </complexType>

            <complexType name="DatumMogelijkOnvolledig">

                        <sequence>

                                    <element name="datumMogelijkOnvolledig" type="StUF:DatumMogelijkOnvolledigType"/>

                        </sequence>

                        <attribute ref="StUF:noValue"/>

            </complexType>

            <complexType name="DatumMogelijkOnvolledigType">

                        <choice>

                                    <element name="datum" type="date"/>

                                    <element name="jaarMaand" type="gMonth"/>

                                    <element name="jaar" type="gYear"/>

                        </choice>

            </complexType>

Helaas  kan een volledige datum nu op twee verschillende manier worden uitgedrukt, namelijk: 

<geboortedatum>1957-08-13</geboortedatum>  

<geboortedatum>

            <datumMogelijkOnvolledig>

                        <datum>1957-08-13</datum>

            </datumMogelijkOnvolledig>

</geboortedatum>

Dit lijkt mij ongewenst. Mijn voorstel is om het (onnodige) container-element “datumMogelijkOnvolledig” te verwijderen uit het complexType “DatumMogelijkOnvolledig” en het complexType “Datum-e” een restriction te laten zijn van complexType “DatumMogelijkOnvolledig”. In dat geval heeft een volledige datum altijd dezelfde syntax:

<geboortedatum>

            <datum>1957-08-13</datum>

</geboortedatum>

Voor consistente naamgeving zou ik het complexType “DatumMogelijkOnvolledig” hernoemen naar “DatumMogelijkOnvolledig-e” omdat dit complexType het attribute StUF:noValue bevat.

In de bijlage van deze post heb ik een nieuwe versie  van het stuf0302.xsd schema toegevoegd waarin de bovenstaande inzichten zijn verwerkt.

Bij nadere analyse ben ik het toch niet eens met de bovenstaande conclusie. Immers het container-element "datumMogelijkOnvolledig" is naar mijn mening volledig overbodig, heeft geen meerwaarde en maakt de standaard onnodig complex. In de definitie van het GAB wordt dit container-element ook helemaal niet genoemd of voorgeschreven. De stelseldefinitie refereert slechts naar het complexType "DatumMogelijkOnvolledig". Volgens mij is het onnodige container-element "datumMogelijkOnvolledig" per ongeluk geïntroduceerd in een voorbeeld van de betreffende GAB-specificatie. Dit moet snel gecorrigeerd worden. Blijkbaar is het errataproces van het GAB helaas nog niet voldoende ingericht om dit correctievoorstel snel te effectueren.

Wel wil ik me er eventueel bij neerleggen om twee verschillende representaties van een volledige datum te accepteren (even zonder de nieuwe syntax voor nillables voor de eenvoud):

<openingsdatum>1957-08-13</openingsdatum>

<geboortedatum>
     <datum>1957-08-13</datum>
</geboortedatum>

Dit zijn dan de schemadefinities:

<xs:element name="openingsdatum" type="xs:date"/>

<xs:element name="geboorte" type="StUF:DatumMogelijkOnvolledig"/>

<xs:complexType name="DatumMogelijkOnvolledig">
     <xs:choice minOccurs="0" maxOccurs="1">
          <xs:element name="datum" type="xs:date"/>
          <xs:element name="jaarMaand" type="xs:gYearMonth"/>
          <xs:element name="jaar" type="xs:gYear"/>
     </xs:choice>
</xs:complexType>

Ik hoop dat ik hiermee tegemoet kom aan de wensen van Sid...

In de laatste versie van het (concept)schema stuf0302.xsd staat de volgende definitie:

<complexType name="TijdstipMogelijkOnvolledigType">
    <choice>
         <element name="tijdstip" type="dateTime"/>
         <element name="jaarMaand" type="gMonth"/>
         <element name="jaar" type="gYear"/>
    </choice>
 </complexType>

Deze definitie is niet correct omdat je in het type "dateTime" verplicht wordt om een tijd mee te geven. Bijvoorbeeld, 2001-12-17T09:30:00 voldoet wel aan dateTime, maar alleen het datumdeel 2001-12-17 voldoet niet. Dit probleem kan verholpen worden met de volgende aanpassing:

<complexType name="TijdstipMogelijkOnvolledigType">
    <choice>
         <element name="tijdstip" type="dateTime"/>
         <element name="datum" type="date"/>
         <element name="jaarMaand" type="gMonth"/>
         <element name="jaar" type="gYear"/>
    </choice>
 </complexType>

Ook stel ik voor het complexType "TijdstipMogelijkOnvolledigType" te hernoemen in "TijdstipMogelijkOnvolledig" omdat dat consequent is met de huidige naamgeving van complex types binnen StUF.

De types time en dateTime hebben twee representaties voor klokslag 12:00 's nachts, namelijk:

• 00:00:00, en
• 24:00:00

StUF 3.01 staat alleen de eerste representatie toe en het lijkt me logisch om dezelfde conventie te behouden in StUF 3.02. Echter we kunnen deze eis niet afdwingen op schemaniveau en zullen het moeten formuleren in de tekst van de documentatie. Niet vergeten dus.

De 24:00:00 notatie wordt op heel erg weinig plekken gebruik en is meer een theoretische aanduiding van het eind van de dag.

Wanneer je dit in b.v. PHP, Java en mogelijk ook andere talen een datetime ontvangt van b.v. 2016-04-20T24:00:00:00 en deze in een Date, Calendar of een dergelijk Object plaatst dan wordt daar automatisch 2016-04-21T00:00:00 van gemaakt.

Om af te dwingen dat er geen 24:00:00 in een datetime gestuurd kan worden kan je het datetime element in de XSD op de volgende manier beperken:

xsd:simpleType>
   <xsd:restriction base="xsd:dateTime">
      <xsd:pattern value="\d{4}-\d\d-\d\dT\d\d:(0[0-9]|1[0-9]|2[0-3]):\d\d[+\-]\d\d:\d\d" />
   </xsd:restriction>
</xsd:simpleType>

Dus gebruik van tijdstip 24:00:00 kan in de praktijk vaak tot gevolg hebben dat een verkeerde datum gebruikt wordt.

Daarom ben ik voorstander van het beperken van een dateTime op de manier die hierboven beschreven is.

Robert,

De 2 post boven die van jou geven aan dat er is een deel van de Expertgroep is die vindt dat 24:00:00 niet meer gebruikt moet worden.

Eens met Lex. In post 14 toont hij heel duidelijk aan waarom 24:00:00 niet meer gebruikt mag worden.

Het pattern  in bovenstaande post #14 klopt niet. Bijv. het correcte tijdstip 2016-04-21T00:00:00 wordt niet gevalideerd. 

Naar aanleiding van de afgelopen bijeenkomst van de expertgroep heb ik de definitie van het complex type "TijdstipMogelijkOnvolledigType" als volgt aangepast:

<complexType name="TijdstipMogelijkOnvolledig-e">
    <choice>
        <element name="tijdstip" type="StUF:DateTime"/>
       <element name="datum" type="date"/>
    </choice>
    <attribute ref="StUF:noValue"/>
 </complexType>

<simpleType name="DateTime">
      <restriction base="dateTime">
          <!--<pattern value="\d{4}-\d\d-\d\dT\d\d:(0[0-9]|1[0-9]|2[0-3]):\d\d[+\-]\d\d:\d\d"/>-->
         <!--bovenstaan pattern is bedoeld om 24:00:00 uit te sluiten, helaas is het pattern nog niet correct. Moet nog worden aangepast-->
     </restriction>
 </simpleType>

Dit zijn de verschillen:

• De elementen jaarMaand en jaar zijn weggelaten
• Attribute noValue toegevoegd
• Naam TijdstipMogelijkOnvolledigType hernoemt naar TijdstipMogelijkOnvolledig-e
• Een pattern op dateTime om 24:00:00 uit te sluiten

Het volledige stuf0302.xsd schema is bijgevoegd.

In post #14 schrijft Lex: "Wanneer je dit in b.v. PHP, Java en mogelijk ook andere talen een datetime ontvangt van b.v. 2016-04-20T24:00:00:00 en deze in een Date, Calendar of een dergelijk Object plaatst dan wordt daar automatisch 2016-04-21T00:00:00 van gemaakt." met in de volgende post de conclusie dat een dateTime met tijdstip 24:00:00 verkeerd wordt vertaald (verkeerde datum).

Ik ben het daar niet mee eens. De XML-documentatie (https://www.w3.org/TR/xmlschema-2/#dateTime) stelt namelijk:"hh is a two-digit numeral that represents the hour; '24' is permitted if the minutes and seconds represented are zero, and the dateTime value so represented is the first instant of the following day (the hour property of a dateTime object in the ·value space· cannot have a value greater than 23);"

Hier wordt dus gesteld dat 24:00:00 alleen toegestaan is als representatie van het eerste tijdstip op de dag erna (dus voor de waarde datum + 1, tijdstip 00:00:00). Dit is ook de omzetting die Lex beschrijft in zijn post #14. Afgezien van het feit dat de XML standaard hier wellicht niet erg intuitief is, lijkt het toch allemaal binnen de regeltjes te vallen. Waarom zouden wij af gaan wijken van de onderliggende standaard?

Hoi Sid, ik begrijp je punt maar ik vrees dat niet alle omgevingen de niet-intuïtieve definitie van XML respecteren. In .NET / C# krijg ik een error als ik 2016-04-20T24:00:00:00 invoer. Bijv. de volgende code-line

Console.WriteLine(new DateTime(2016, 4, 20, 24, 0, 0).ToString());

leidt tot de melding

An unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
Additional information: Met de parameters voor uur, minuut en seconde wordt een niet weer te geven DateTime beschreven.

Ik vraag me af of het verstandig is om jaarmaand en jaar te verwijderen uit TijdstipMogelijkOnvolledig, omdat dit type wordt gebruikt binnen StUF:begin/eindGeldigheid en StUF:begin/eindRelatie. De BRP staat bij mijn weten toe dat deze elementen een onvolledige datum mogen bevatten en dat kan dan niet langer. Daarnaast vraag ik me af hoe je het nillable="true" vermijdt met het voorstel uit post 20.

Ik kan me vinden in het uitsluiten van 24:00:00:000 binnen de tijd, omdat niet alle implementaties hiermee overweg blijken te kunnen.

Wat mij betreft prima om jaarMaand en jaar weer terug te zetten in TijdstipMogelijkOnvolledig-e, eigenlijk graag zelfs want ik ben een voorstander om de StUF-onderlaag zo volledig mogelijk te laten zijn. Alleen dacht ik dat we in de afgelopen expertgroep gezamenlijk besloten hadden om jaarMaand en jaar weg te laten om een compromis te bereiken. Gelukkig ben ik blijkbaar abuis.

In het bovenstaande voorstel gebruik ik de huidige 3.01 syntax voor lege waarden (dus het attribute StUF:noValue in combinatie met nillable="true"). Echter de XSD-definitie is eenvoudig om te zetten conform RFC0413:

<complexType name="TijdstipMogelijkOnvolledig-e">
    <choice>
        <element name="tijdstip" type="StUF:DateTime"/>
        <element name="datum" type="date"/>
        <element name="jaarMaand" type="gMonth"/>
        <element name="jaar" type="gYear"/>
        <element name="leeg" type="StUF:NoValue"/>
    </choice>
</complexType>

In deze definitie heb ik meteen de kans gegrepen om jaarMaand en jaar in ere te herstellen.

De XML standaard welke refereert naar de ISO-8601 schrijft het volgende:

- In 3.2.7.1 Lexical representation

* hh is a two-digit numeral that represents the hour; '24' is permitted if the minutes and seconds represented are zero, and the dateTime value so represented is the first instant of the following day (the hour property of a dateTime object in the ·value space· cannot have a value greater than 23);

De ISO-8601 zelf schrijft het volgende:

* [hh] refers to a zero-padded hour between 00 and 24 (where 24 is only used to denote midnight at the end of a calendar day).

Ondanks dat de XML standaard refereert naar de ISO-8601, interpreteren ze de betekenis van 24:00:00 anders.

Dat de meeste programmeertalen de dateTime  2016-04-20T24:00:00:00 automatisch naar 2016-04-21T00:00:00 omzet of zelfs een exceptie gooien, is niet iets waar je het niet mee eens of oneens kan zijn. Het is heel simpel een feit dat dit gebeurd.

Ook hebben we getest hoe Postgres en Oracle hier mee omgaan.

Het resultaat in Postgres:

merijn=create table foo (c_foo integer, foo timestamp);
CREATE TABLE
merijn=# insert into foo values (1,'2016-04-20T24:00:00');
INSERT 0 1
merijn=# select * from foo;
 c_foo |         foo
-------+---------------------
     1 | 2016-04-21 00:00:00

Het resultaat in Oracle:

SQL> create table foo (c_foo integer, foo timestamp);
Table created.
SQL> insert into foo values (1, to_timestamp ('2016-04-20 24:00:00','YYYY-MM-DD HH24:MI:SS'))
                                         *
ERROR at line 1:
ORA-01850: hour must be between 0 and 23

Als een zendend of ontvangend systeem niet goed of helemaal niet overweg kan met de 24:00:00 notatie in een dateTime veld, waarom zouden we dit dan toestaan als het niet hoeft en waarschijnlijk voor onnodige problemen zorgt

Wanneer een zendende partij straks een kennisgevingsbericht stuurt met daarin ergens een dateTime van 2016-04-20T24:00:00:00, wat ga je opslaan en wat geef als antwoord terug wanneer dit object opgevraagd wordt met een vraagbericht?
Eenmaal opgeslagen als iets anders dan 2016-04-20T24:00:00:00 is het niet meer te achterhalen of het ooit een 2016-04-20T24:00:00:00 geweest is of niet

Overigens de juiste regular expression voor dit type is: \d{4}-\d\d-\d\dT(0[0-9]|1[0-9]|2[0-3]):\d\d:\d\d