10 Nov
2021
10 Nov
'21
11:10 a.m.
Hi all,
After the summer vacation, the technical steering meetings didn't continue.
In my opinion, this is fine and we only need to meet if necessary. But, I
think it's necessary to discuss a topic that we're struggling with at the
moment.
*Topic: Adding non-standard API features into Open Zaak*
In short, Open Zaak currently has version 1.0 of all ZGW API's implemented.
The ZGW API specifications however are evolving. Some of these API changes
are needed "now" and the question arrives if we should just add this
filter, this extra field, etc. without moving the entire API to the next
version (because that takes more time/money). Some features might even be
planned for a future version of the specification that is not released yet
(but we need now!)
The question: Should we be allowed to add some of these non-standard
features into Open Zaak (properly documented as a difference, and only if
it's in line with the future of the specifications)?
*Meeting proposal*
I propose to discuss this (and perhaps other topics) in the next meeting,
which I'll schedule on December 8, 14.00. If I don't hear anything before
November 17, I'll assume this date and time are okay.
Best regards,
Joeri Bekker
--
<https://opengem.nl>
Een initiatief van Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl
10 Nov
10 Nov
11:33 a.m.
New subject: Fwd: Open Zaak next technical steering group meeting
Hi all,
After the summer vacation, the technical steering meetings didn't continue.
In my opinion, this is fine and we only need to meet if necessary. But, I
think it's necessary to discuss a topic that we're struggling with at the
moment.
*Topic: Adding non-standard API features into Open Zaak*
In short, Open Zaak currently has version 1.0 of all ZGW API's implemented.
The ZGW API specifications however are evolving. Some of these API changes
are needed "now" and the question arrives if we should just add this
filter, this extra field, etc. without moving the entire API to the next
version (because that takes more time/money). Some features might even be
planned for a future version of the specification that is not released yet
(but we need now!)
The question: Should we be allowed to add some of these non-standard
features into Open Zaak (properly documented as a difference, and only if
it's in line with the future of the specifications)?
*Meeting proposal*
I propose to discuss this (and perhaps other topics) in the next meeting,
which I'll schedule on December 8, 14.00. If I don't hear anything before
November 17, I'll assume this date and time are okay.
Best regards,
Joeri Bekker
--
Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl
12:37 p.m.
New subject: Fwd: Open Zaak next technical steering group meeting
Hi Joeri,
I have similar discussions with respect to the (very immature)
algoritmeregister standard and algoritmeregister management application.
Thinking about it, my solution would be to call such features "pilot"
features, both towards the client and the steering group; if they are
rejected later, the client needs to know that either they will end up with
a non-complient solution, or it will need to be rolled back/switched with
whatever comes in place.
Kind Regards,
Johan
Op wo 10 nov. 2021 11:33 schreef Joeri Bekker via openzaak-discuss <
openzaak-discuss(a)lists.publiccode.net>:
Hi all,
After the summer vacation, the technical steering meetings didn't
continue. In my opinion, this is fine and we only need to meet if
necessary. But, I think it's necessary to discuss a topic that we're
struggling with at the moment.
*Topic: Adding non-standard API features into Open Zaak*
In short, Open Zaak currently has version 1.0 of all ZGW API's
implemented. The ZGW API specifications however are evolving. Some of these
API changes are needed "now" and the question arrives if we should just add
this filter, this extra field, etc. without moving the entire API to the
next version (because that takes more time/money). Some features might even
be planned for a future version of the specification that is not released
yet (but we need now!)
The question: Should we be allowed to add some of these non-standard
features into Open Zaak (properly documented as a difference, and only if
it's in line with the future of the specifications)?
*Meeting proposal*
I propose to discuss this (and perhaps other topics) in the next meeting,
which I'll schedule on December 8, 14.00. If I don't hear anything before
November 17, I'll assume this date and time are okay.
Best regards,
Joeri Bekker
--
Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl
_______________________________________________
openzaak-discuss mailing list -- openzaak-discuss(a)lists.publiccode.net
To unsubscribe send an email to
openzaak-discuss-leave(a)lists.publiccode.net
11 Nov
11 Nov
12:12 p.m.
New subject: Fwd: Open Zaak next technical steering group meeting
Hi All,
My 2 cents:
* OpenZaak was created to support the ZGW API's in a production environment, also
newer versions of the ZGW API spec (but I would advise against cherry picking features in
newer version and creating a half version in conflict with the ZGW API spec version)
* If a client (or more clients) wants to develop extra API's or build on top of
ZGW API (not in conflict with ZGW API) this can be provided by the supplier of the
customer (as part of an extra module but not merged in OpenZaak repo) & maybe Create a
new version of the ZGW API (via the 'Technische gebruikersgroep API standaard voor
Zaakgericht werken' session)
* If a client (or more clients) want to change something from OpenZaak which is in
conflict with the ZGW API, we have 2 options:
* Create a new version of the ZGW API (via the 'Technische gebruikersgroep API
standaard voor Zaakgericht werken' session)
* Create and manage a different solution/product than OpenZaak
Kind regards,
Silvion Moesan
Van: Johan Groenen via openzaak-discuss <openzaak-discuss(a)lists.publiccode.net>
Verzonden: woensdag 10 november 2021 12:37
Aan: Joeri Bekker <joeri(a)maykinmedia.nl>
CC: Open Zaak discuss <openzaak-discuss(a)lists.publiccode.net>; Joeri Bekker
<joeri.bekker(a)maykinmedia.nl>; Johan Groenen <johan(a)tiltshift.nl>
Onderwerp: [OpenZaak-discuss] Re: Fwd: Open Zaak next technical steering group meeting
Hi Joeri,
I have similar discussions with respect to the (very immature) algoritmeregister standard
and algoritmeregister management application. Thinking about it, my solution would be to
call such features "pilot" features, both towards the client and the steering
group; if they are rejected later, the client needs to know that either they will end up
with a non-complient solution, or it will need to be rolled back/switched with whatever
comes in place.
Kind Regards,
Johan
Op wo 10 nov. 2021 11:33 schreef Joeri Bekker via openzaak-discuss
<openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>>:
Hi all,
After the summer vacation, the technical steering meetings didn't continue. In my
opinion, this is fine and we only need to meet if necessary. But, I think it's
necessary to discuss a topic that we're struggling with at the moment.
Topic: Adding non-standard API features into Open Zaak
In short, Open Zaak currently has version 1.0 of all ZGW API's implemented. The ZGW
API specifications however are evolving. Some of these API changes are needed
"now" and the question arrives if we should just add this filter, this extra
field, etc. without moving the entire API to the next version (because that takes more
time/money). Some features might even be planned for a future version of the specification
that is not released yet (but we need now!)
The question: Should we be allowed to add some of these non-standard features into Open
Zaak (properly documented as a difference, and only if it's in line with the future of
the specifications)?
Meeting proposal
I propose to discuss this (and perhaps other topics) in the next meeting, which I'll
schedule on December 8, 14.00. If I don't hear anything before November 17, I'll
assume this date and time are okay.
Best regards,
Joeri Bekker
--
Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl<https://eur02.safelinks.protection.outlook.c...
_______________________________________________
openzaak-discuss mailing list --
openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>
To unsubscribe send an email to
openzaak-discuss-leave@lists.publiccode.net<mailto:openzaak-discuss-leave@lists.publiccode.net>
2:03 p.m.
New subject: Fwd: Open Zaak next technical steering group meeting
I'm happy to see input from people not part of the technical steering
group! Please keep it coming and then we can take all those remarks into
consideration when we effectively discuss it during a TSG meeting.
On Thu, Nov 11, 2021 at 1:25 PM Silvion Moesan via openzaak-discuss <
openzaak-discuss(a)lists.publiccode.net> wrote:
Hi All,
My 2 cents:
- OpenZaak was created to support the ZGW API’s in a production
environment, also newer versions of the ZGW API spec (but I would advise
against cherry picking features in newer version and creating a half
version in conflict with the ZGW API spec version)
- If a client (or more clients) wants to develop extra API’s or build
on top of ZGW API (not in conflict with ZGW API) this can be provided by
the supplier of the customer (as part of an extra module but not merged in
OpenZaak repo) & maybe Create a new version of the ZGW API (via the
‘Technische gebruikersgroep API standaard voor Zaakgericht werken’ session)
- If a client (or more clients) want to change something from OpenZaak
which is in conflict with the ZGW API, we have 2 options:
- Create a new version of the ZGW API (via the ‘Technische
gebruikersgroep API standaard voor Zaakgericht werken’ session)
- Create and manage a different solution/product than OpenZaak
Kind regards,
Silvion Moesan
*Van:* Johan Groenen via openzaak-discuss <
openzaak-discuss(a)lists.publiccode.net>
*Verzonden:* woensdag 10 november 2021 12:37
*Aan:* Joeri Bekker <joeri(a)maykinmedia.nl>
*CC:* Open Zaak discuss <openzaak-discuss(a)lists.publiccode.net>; Joeri
Bekker <joeri.bekker(a)maykinmedia.nl>; Johan Groenen <johan(a)tiltshift.nl>
*Onderwerp:* [OpenZaak-discuss] Re: Fwd: Open Zaak next technical
steering group meeting
Hi Joeri,
I have similar discussions with respect to the (very immature)
algoritmeregister standard and algoritmeregister management application.
Thinking about it, my solution would be to call such features "pilot"
features, both towards the client and the steering group; if they are
rejected later, the client needs to know that either they will end up with
a non-complient solution, or it will need to be rolled back/switched with
whatever comes in place.
Kind Regards,
Johan
Op wo 10 nov. 2021 11:33 schreef Joeri Bekker via openzaak-discuss <
openzaak-discuss(a)lists.publiccode.net>:
Hi all,
After the summer vacation, the technical steering meetings didn't
continue. In my opinion, this is fine and we only need to meet if
necessary. But, I think it's necessary to discuss a topic that we're
struggling with at the moment.
*Topic: Adding non-standard API features into Open Zaak*
In short, Open Zaak currently has version 1.0 of all ZGW API's
implemented. The ZGW API specifications however are evolving. Some of these
API changes are needed "now" and the question arrives if we should just add
this filter, this extra field, etc. without moving the entire API to the
next version (because that takes more time/money). Some features might even
be planned for a future version of the specification that is not released
yet (but we need now!)
The question: Should we be allowed to add some of these non-standard
features into Open Zaak (properly documented as a difference, and only if
it's in line with the future of the specifications)?
*Meeting proposal*
I propose to discuss this (and perhaps other topics) in the next meeting,
which I'll schedule on December 8, 14.00. If I don't hear anything before
November 17, I'll assume this date and time are okay.
Best regards,
Joeri Bekker
--
Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl
<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mayk...
_______________________________________________
openzaak-discuss mailing list -- openzaak-discuss(a)lists.publiccode.net
To unsubscribe send an email to
openzaak-discuss-leave(a)lists.publiccode.net
_______________________________________________
openzaak-discuss mailing list -- openzaak-discuss(a)lists.publiccode.net
To unsubscribe send an email to
openzaak-discuss-leave(a)lists.publiccode.net
2:25 p.m.
New subject: Fwd: Open Zaak next technical steering group meeting
Hi all,
For some reason I am in this email group, although I am not involved in OpenZaak. So what
I am suggesting may be a completely silly idea. With that disclaimer, while I am here... I
have worked with API's 100 years ago that had a separate <extension> field, in
which you could submit structured data in whatever format you choose. This allows people
to extend the original spec, without changing it. Whenever an extension becomes used a lot
/ stable, you can move it to the parent API 2.0 spec. Again, this was 100 years ago, so
it's just a suggestion, feel free to discard it.
Best regards,
Edo Plantinga
Projectmanager KISS & Demodam
________________________________
Van: Silvion Moesan via openzaak-discuss <openzaak-discuss(a)lists.publiccode.net>
Verzonden: donderdag 11 november 2021 12:12
Aan: Johan Groenen via openzaak-discuss <openzaak-discuss(a)lists.publiccode.net>;
Joeri Bekker <joeri(a)maykinmedia.nl>
CC: Joeri Bekker <joeri.bekker(a)maykinmedia.nl>; Johan Groenen
<johan(a)tiltshift.nl>; Silvion Moesan <silvion.moesan(a)open.nl>
Onderwerp: [OpenZaak-discuss] Re: Fwd: Open Zaak next technical steering group meeting
Hi All,
My 2 cents:
* OpenZaak was created to support the ZGW API’s in a production environment, also
newer versions of the ZGW API spec (but I would advise against cherry picking features in
newer version and creating a half version in conflict with the ZGW API spec version)
* If a client (or more clients) wants to develop extra API’s or build on top of ZGW
API (not in conflict with ZGW API) this can be provided by the supplier of the customer
(as part of an extra module but not merged in OpenZaak repo) & maybe Create a new
version of the ZGW API (via the ‘Technische gebruikersgroep API standaard voor Zaakgericht
werken’ session)
* If a client (or more clients) want to change something from OpenZaak which is in
conflict with the ZGW API, we have 2 options:
* Create a new version of the ZGW API (via the ‘Technische gebruikersgroep API
standaard voor Zaakgericht werken’ session)
* Create and manage a different solution/product than OpenZaak
Kind regards,
Silvion Moesan
Van: Johan Groenen via openzaak-discuss <openzaak-discuss(a)lists.publiccode.net>
Verzonden: woensdag 10 november 2021 12:37
Aan: Joeri Bekker <joeri(a)maykinmedia.nl>
CC: Open Zaak discuss <openzaak-discuss(a)lists.publiccode.net>; Joeri Bekker
<joeri.bekker(a)maykinmedia.nl>; Johan Groenen <johan(a)tiltshift.nl>
Onderwerp: [OpenZaak-discuss] Re: Fwd: Open Zaak next technical steering group meeting
Hi Joeri,
I have similar discussions with respect to the (very immature) algoritmeregister standard
and algoritmeregister management application. Thinking about it, my solution would be to
call such features "pilot" features, both towards the client and the steering
group; if they are rejected later, the client needs to know that either they will end up
with a non-complient solution, or it will need to be rolled back/switched with whatever
comes in place.
Kind Regards,
Johan
Op wo 10 nov. 2021 11:33 schreef Joeri Bekker via openzaak-discuss
<openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>>:
Hi all,
After the summer vacation, the technical steering meetings didn't continue. In my
opinion, this is fine and we only need to meet if necessary. But, I think it's
necessary to discuss a topic that we're struggling with at the moment.
Topic: Adding non-standard API features into Open Zaak
In short, Open Zaak currently has version 1.0 of all ZGW API's implemented. The ZGW
API specifications however are evolving. Some of these API changes are needed
"now" and the question arrives if we should just add this filter, this extra
field, etc. without moving the entire API to the next version (because that takes more
time/money). Some features might even be planned for a future version of the specification
that is not released yet (but we need now!)
The question: Should we be allowed to add some of these non-standard features into Open
Zaak (properly documented as a difference, and only if it's in line with the future of
the specifications)?
Meeting proposal
I propose to discuss this (and perhaps other topics) in the next meeting, which I'll
schedule on December 8, 14.00. If I don't hear anything before November 17, I'll
assume this date and time are okay.
Best regards,
Joeri Bekker
--
Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl<https://eur02.safelinks.protection.outlook.c...
_______________________________________________
openzaak-discuss mailing list --
openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>
To unsubscribe send an email to
openzaak-discuss-leave@lists.publiccode.net<mailto:openzaak-discuss-leave@lists.publiccode.net>
5:20 p.m.
New subject: Fwd: Open Zaak next technical steering group meeting
Well Edo... This was indeed how it was 100 years ago and it was one of the
worst ideas ever.
In short, this construction was misused by suppliers who added complete new
specifications inside the specifications making server and client apps
incompatible.
Vriendelijke groet / Best regards,
Joeri Bekker
(verzonden vanaf mobiel)
--
Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl
Op do 11 nov. 2021 14:25 schreef Edo Plantinga via openzaak-discuss <
openzaak-discuss(a)lists.publiccode.net>:
Hi all,
For some reason I am in this email group, although I am not involved in
OpenZaak. So what I am suggesting may be a completely silly idea. With that
disclaimer, while I am here... I have worked with API's 100 years ago that
had a separate <extension> field, in which you could submit structured data
in whatever format you choose. This allows people to extend the original
spec, without changing it. Whenever an extension becomes used a lot /
stable, you can move it to the parent API 2.0 spec. Again, this was 100
years ago, so it's just a suggestion, feel free to discard it.
Best regards,
Edo Plantinga
Projectmanager KISS & Demodam
------------------------------
*Van:* Silvion Moesan via openzaak-discuss <
openzaak-discuss(a)lists.publiccode.net>
*Verzonden:* donderdag 11 november 2021 12:12
*Aan:* Johan Groenen via openzaak-discuss <
openzaak-discuss(a)lists.publiccode.net>; Joeri Bekker <joeri(a)maykinmedia.nl
*CC:* Joeri Bekker
<joeri.bekker(a)maykinmedia.nl>; Johan Groenen <
johan(a)tiltshift.nl>; Silvion Moesan <silvion.moesan(a)open.nl>
*Onderwerp:* [OpenZaak-discuss] Re: Fwd: Open Zaak next technical
steering group meeting
Hi All,
My 2 cents:
- OpenZaak was created to support the ZGW API’s in a production
environment, also newer versions of the ZGW API spec (but I would advise
against cherry picking features in newer version and creating a half
version in conflict with the ZGW API spec version)
- If a client (or more clients) wants to develop extra API’s or build
on top of ZGW API (not in conflict with ZGW API) this can be provided by
the supplier of the customer (as part of an extra module but not merged in
OpenZaak repo) & maybe Create a new version of the ZGW API (via the
‘Technische gebruikersgroep API standaard voor Zaakgericht werken’ session)
- If a client (or more clients) want to change something from OpenZaak
which is in conflict with the ZGW API, we have 2 options:
- Create a new version of the ZGW API (via the ‘Technische
gebruikersgroep API standaard voor Zaakgericht werken’ session)
- Create and manage a different solution/product than OpenZaak
Kind regards,
Silvion Moesan
*Van:* Johan Groenen via openzaak-discuss <
openzaak-discuss(a)lists.publiccode.net>
*Verzonden:* woensdag 10 november 2021 12:37
*Aan:* Joeri Bekker <joeri(a)maykinmedia.nl>
*CC:* Open Zaak discuss <openzaak-discuss(a)lists.publiccode.net>; Joeri
Bekker <joeri.bekker(a)maykinmedia.nl>; Johan Groenen <johan(a)tiltshift.nl>
*Onderwerp:* [OpenZaak-discuss] Re: Fwd: Open Zaak next technical
steering group meeting
Hi Joeri,
I have similar discussions with respect to the (very immature)
algoritmeregister standard and algoritmeregister management application.
Thinking about it, my solution would be to call such features "pilot"
features, both towards the client and the steering group; if they are
rejected later, the client needs to know that either they will end up with
a non-complient solution, or it will need to be rolled back/switched with
whatever comes in place.
Kind Regards,
Johan
Op wo 10 nov. 2021 11:33 schreef Joeri Bekker via openzaak-discuss <
openzaak-discuss(a)lists.publiccode.net>:
Hi all,
After the summer vacation, the technical steering meetings didn't
continue. In my opinion, this is fine and we only need to meet if
necessary. But, I think it's necessary to discuss a topic that we're
struggling with at the moment.
*Topic: Adding non-standard API features into Open Zaak*
In short, Open Zaak currently has version 1.0 of all ZGW API's
implemented. The ZGW API specifications however are evolving. Some of these
API changes are needed "now" and the question arrives if we should just add
this filter, this extra field, etc. without moving the entire API to the
next version (because that takes more time/money). Some features might even
be planned for a future version of the specification that is not released
yet (but we need now!)
The question: Should we be allowed to add some of these non-standard
features into Open Zaak (properly documented as a difference, and only if
it's in line with the future of the specifications)?
*Meeting proposal*
I propose to discuss this (and perhaps other topics) in the next meeting,
which I'll schedule on December 8, 14.00. If I don't hear anything before
November 17, I'll assume this date and time are okay.
Best regards,
Joeri Bekker
--
Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl
<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mayk...
_______________________________________________
openzaak-discuss mailing list -- openzaak-discuss(a)lists.publiccode.net
To unsubscribe send an email to
openzaak-discuss-leave(a)lists.publiccode.net
_______________________________________________
openzaak-discuss mailing list -- openzaak-discuss(a)lists.publiccode.net
To unsubscribe send an email to
openzaak-discuss-leave(a)lists.publiccode.net
12 Nov
12 Nov
9:32 a.m.
New subject: Fwd: Open Zaak next technical steering group meeting
Ha ha, glad to hear that my intuition it was a silly idea was right 😉.
________________________________
Van: Joeri Bekker via openzaak-discuss <openzaak-discuss(a)lists.publiccode.net>
Verzonden: donderdag 11 november 2021 17:20
Aan: Edo Plantinga via openzaak-discuss <openzaak-discuss(a)lists.publiccode.net>
CC: Joeri Bekker <joeri.bekker(a)maykinmedia.nl>
Onderwerp: [OpenZaak-discuss] Re: Fwd: Open Zaak next technical steering group meeting
Well Edo... This was indeed how it was 100 years ago and it was one of the worst ideas
ever.
In short, this construction was misused by suppliers who added complete new specifications
inside the specifications making server and client apps incompatible.
Vriendelijke groet / Best regards,
Joeri Bekker
(verzonden vanaf mobiel)
--
Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl
Op do 11 nov. 2021 14:25 schreef Edo Plantinga via openzaak-discuss
<openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>>:
Hi all,
For some reason I am in this email group, although I am not involved in OpenZaak. So what
I am suggesting may be a completely silly idea. With that disclaimer, while I am here... I
have worked with API's 100 years ago that had a separate <extension> field, in
which you could submit structured data in whatever format you choose. This allows people
to extend the original spec, without changing it. Whenever an extension becomes used a lot
/ stable, you can move it to the parent API 2.0 spec. Again, this was 100 years ago, so
it's just a suggestion, feel free to discard it.
Best regards,
Edo Plantinga
Projectmanager KISS & Demodam
________________________________
Van: Silvion Moesan via openzaak-discuss
<openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>>
Verzonden: donderdag 11 november 2021 12:12
Aan: Johan Groenen via openzaak-discuss
<openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>>;
Joeri Bekker <joeri@maykinmedia.nl<mailto:joeri@maykinmedia.nl>>
CC: Joeri Bekker
<joeri.bekker@maykinmedia.nl<mailto:joeri.bekker@maykinmedia.nl>>; Johan
Groenen <johan@tiltshift.nl<mailto:johan@tiltshift.nl>>; Silvion Moesan
<silvion.moesan@open.nl<mailto:silvion.moesan@open.nl>>
Onderwerp: [OpenZaak-discuss] Re: Fwd: Open Zaak next technical steering group meeting
Hi All,
My 2 cents:
* OpenZaak was created to support the ZGW API’s in a production environment, also
newer versions of the ZGW API spec (but I would advise against cherry picking features in
newer version and creating a half version in conflict with the ZGW API spec version)
* If a client (or more clients) wants to develop extra API’s or build on top of ZGW
API (not in conflict with ZGW API) this can be provided by the supplier of the customer
(as part of an extra module but not merged in OpenZaak repo) & maybe Create a new
version of the ZGW API (via the ‘Technische gebruikersgroep API standaard voor Zaakgericht
werken’ session)
* If a client (or more clients) want to change something from OpenZaak which is in
conflict with the ZGW API, we have 2 options:
* Create a new version of the ZGW API (via the ‘Technische gebruikersgroep API
standaard voor Zaakgericht werken’ session)
* Create and manage a different solution/product than OpenZaak
Kind regards,
Silvion Moesan
Van: Johan Groenen via openzaak-discuss
<openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>>
Verzonden: woensdag 10 november 2021 12:37
Aan: Joeri Bekker <joeri@maykinmedia.nl<mailto:joeri@maykinmedia.nl>>
CC: Open Zaak discuss
<openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>>;
Joeri Bekker
<joeri.bekker@maykinmedia.nl<mailto:joeri.bekker@maykinmedia.nl>>; Johan
Groenen <johan@tiltshift.nl<mailto:johan@tiltshift.nl>>
Onderwerp: [OpenZaak-discuss] Re: Fwd: Open Zaak next technical steering group meeting
Hi Joeri,
I have similar discussions with respect to the (very immature) algoritmeregister standard
and algoritmeregister management application. Thinking about it, my solution would be to
call such features "pilot" features, both towards the client and the steering
group; if they are rejected later, the client needs to know that either they will end up
with a non-complient solution, or it will need to be rolled back/switched with whatever
comes in place.
Kind Regards,
Johan
Op wo 10 nov. 2021 11:33 schreef Joeri Bekker via openzaak-discuss
<openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>>:
Hi all,
After the summer vacation, the technical steering meetings didn't continue. In my
opinion, this is fine and we only need to meet if necessary. But, I think it's
necessary to discuss a topic that we're struggling with at the moment.
Topic: Adding non-standard API features into Open Zaak
In short, Open Zaak currently has version 1.0 of all ZGW API's implemented. The ZGW
API specifications however are evolving. Some of these API changes are needed
"now" and the question arrives if we should just add this filter, this extra
field, etc. without moving the entire API to the next version (because that takes more
time/money). Some features might even be planned for a future version of the specification
that is not released yet (but we need now!)
The question: Should we be allowed to add some of these non-standard features into Open
Zaak (properly documented as a difference, and only if it's in line with the future of
the specifications)?
Meeting proposal
I propose to discuss this (and perhaps other topics) in the next meeting, which I'll
schedule on December 8, 14.00. If I don't hear anything before November 17, I'll
assume this date and time are okay.
Best regards,
Joeri Bekker
--
Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
http://www.maykinmedia.nl<https://eur02.safelinks.protection.outlook.c...
_______________________________________________
openzaak-discuss mailing list --
openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>
To unsubscribe send an email to
openzaak-discuss-leave@lists.publiccode.net<mailto:openzaak-discuss-leave@lists.publiccode.net>
_______________________________________________
openzaak-discuss mailing list --
openzaak-discuss@lists.publiccode.net<mailto:openzaak-discuss@lists.publiccode.net>
To unsubscribe send an email to
openzaak-discuss-leave@lists.publiccode.net<mailto:openzaak-discuss-leave@lists.publiccode.net>
567
days inactive
569
days old
openzaak-discuss@lists.publiccode.net
7 comments
5 participants
participants (5)
-
Edo Plantinga -
Joeri Bekker -
Johan Groenen -
Sergei Maertens -
Silvion Moesan