Functionality added : conformance level description

[Thomas Sødring]

On 12/02/2016 10:37 AM, Petter Reinholdtsen wrote:
> [Thomas Sødring]
>> Your understanding is correct, so maybe we are just saying the same
>> thing but differently.  byggesak will be a third api as it has it's
>> own metadata that is not part of sakarkiv. Technically, if byggesak
>> extends from sakarkiv, you will be able to search byggesak records
>> within the sakarkiv interface, but you won't get all the metadata! If
>> it extends from File (mappe), then you will have a different route! I
>> have a masters currently looking at the byggesak metadata, so we might
>> be able to push this for the record keeping community in
>> Norway. Trondheim kommune have done some work on this but it was based
>> on scanning historic documents.
> The use case I have in mind is searching, and when I search the official
> API for case files, I expect to find what I am searching for all case
> files I have access to, even byggesak ones.  It would be OK if I did not
> get all the metadata, as long as there was a way to notice that there
> are more metadata available using some other API.
As long as byggesak extends sakarkiv, that will work. But in general, we
are years away from Noark being used properly. I took the vendors 5-6
years to get "endelig godkjenning".  I think as we progress with the
codebase, you might ask why it took them so long! My interpretation is
that the vendors products are very different with regards to flexibility
and over the last few years they have become much more flexible.

My hope with this open source core is that we will not be dependent on
the big three vendors to actually play around and further develop record
keeping. Today if you don't have one of the big three on board, it's
practically impossible to do any innovation. And innovation will cost!
Documaster, that share (or did share) the same domain model as nikita,
have been very innovative, but they are still  protecting the core
product. We really do need open source in this space!

With regards to innovation, one of things I've been talking to others
recently about is to implement block-chain technology for signing
documents. Testing this kind of thing will be so much easier  in an open
source code base. No need for contracts with vendors and IP questions
and fees. You can just try it out yourself! I think an open source core
can help with the digitisation of the public sector. If people could
just accept the role of a record keeping core in the IT architecture.

BTW, NIKITA originally stood for *N*orsk *I*nterkommunalt *IT*
*A*rkitektur, but I have learnt there is no point in trying to build up
a community with municipalities. KS has zero interest. So now it stands
for something like   Norsk  IKT Interoperabilts Arkitektur  (extra i in
the middle) where the core is hopefully part of an open source IT
architecture including open source LDAP, Libre Office etc. But I don't
think I have what is required to build the architecture, but if NUUG or
others want to help build NIKITA that would be great, with this project,
you'll get the core!
>
>> Can you post your response? This is my reponse:
> The GET request used these headers, according to Chromium Inspect:
>
> Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Accept-Encoding:gzip, deflate, sdch
> Accept-Language:en-US,en;q=0.8
> Cache-Control:max-age=0
> Connection:keep-alive
> Cookie:JSESSIONID=B6DDFD8CDA319A9B0145A67B0D0A0536
> Host:localhost:8092
> Upgrade-Insecure-Requests:1
> User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
>
> And this was the response header:
>
> Cache-Control:no-cache, no-store, max-age=0, must-revalidate
> Content-Type:application/xhtml+xml;charset=UTF-8
> Date:Fri, 02 Dec 2016 09:32:15 GMT
> Expires:0
> Pragma:no-cache
> Server:Apache-Coyote/1.1
> Transfer-Encoding:chunked
> X-Application-Context:HiOA Noark 5 Core (Demo mode):demo:8092
> X-Content-Type-Options:nosniff
> X-Frame-Options:DENY
> X-XSS-Protection:1; mode=block
>
>> That should explicitly set the content type at the method level. Do you
>> know if your GET request included a
>> Accept: application/xml ?
> It did.
>
> Perhaps it is a good thing that XML is returned when requested?  It this
> according to or breaking the specification?
>

OK, well the core is doing the right thing then returning XML because
you are asking for it. This is one of the nice things about spring, this
is free out-of-the box. I think there are more serializers available as well

But I guess it really should be application/vnd.noark5-v4+xml. As I
introduce functionality I will change accept types to the
vnd.noark5-v4+*. So in may ways the core is kinda breaking the standard.

But as far as  I can tell standard doesn't prohibit me from supporting
generic JSON and XML. I just have to make sure at a minimum that I
support application/vnd.noark5-v4+JSON.

This is also where I might run into issues. If I am writing my own JSON
serializers, then generic XML/JSON will not be serialized properly in
response to a request. So I need responses to be generic so that spring
can automatically do the serialization.

 - Tom