NOARK 5 web service requirements

[Thomas Sødring]

On 02/04/2017 09:01 AM, Petter Reinholdtsen wrote:
> The specification refer to
> <URL: http://rel.kxml.no/noark5/konformitetsniva/ > defining what
> features must be present for an implementation to be conforming.  But
> that list is a bit short.  Is there some more details available
> anywhere?

No, this is one of the outstanding questions I have with the National
Archive.  I think this is going to be very problematic unless they fix
it. The standard is littered with optional requirements and as far as I
can see they have not dealt with this. I guess a Noark core could return
a list of requirements it fulfils. I don't mean to complain, but I find
it a little frustrating that there is a lot of guesswork here. But that
can also be because I don't have many years experience with HATEOAS.

Somebody told me that they released the current version because a lot of
people were asking for it, but that it is work-in-progress. Hence the
Beta tag on it. But it would have been better if they explained how far
they had come and what they themselves believe is missing.

>
> I suspect Nikita already fill the basic level 0 requirements except the
> XML one, but it is unclear to me exactly what each requirement mean.
>
> The list is simply
>
>  * CORS Cross-origin resource sharing
>  * authentication is required
>  * json format is supported
>  * xml format is supported
>
> For example, for CORS, is it enough to be able to do a OPTIONS request,
> or should the requests and answers have particular content?  Anyone
> know?  The test server on "http://n5test.kxml.no/api/" do not support
> OPTIONS at all, so no help there. :(

I do not know the answer to your questions :) I don't mean to be
disingenuous to the National Archive, but I don't think they know either!

I also believe that we now fulfil most of Basic level 0. Seeing as  I
wrote my own serialisers for JSON, I probably have to do the same for
XML.  I think it's unfair to expect XML implementation when there is no
proper XML description, like an XSD! Yes, we can infer it from the JSON
and parameters, but they might suddenly publish a new version of the
interface with lots of changes. Currently I'm not sure if the sakarkiv
part of interface is specified properly

 http://n5test.kxml.no/api/sakarkiv

has no information, but reading the document does give an insight into
dealing with it!

We also need to get a better grip on roles (Only the records management
role has access to change fonds/series) and ownership. The Noark
standard (not including komplett) does not really say anything group
ownership of objects, if I call recall correctly. But group ownership is
very important! No Noark core can just assume objects are solely to be
accessed by individuals! Think of the HR department, groups of people
will have access to a various casefiles.
> I have similar questions about the details for the other three
> requirements too. :)
>

My opinion on this standard is that I think that it's very ambitious.
They didn't just specify a SOAP webservice, they have tried to be a
little ahead.  Eugen at baeldung.com says in his recordings on HATEOAS
that there is no example of a national standard implemented as HATEOAS.
If he is correct, then the NA deserve  praise for trying to do it his way!

The only risk I currently see is dealing with the OData filter syntax. I
was working on this this week and went deep enough that I decided I'd
try to build my own parser for OData syntax. But from what I can tell
from stack overflow the syntax description for OData hosted by OASIS is
not correct! So I can't even write my own parser! So now I'm back to
Apache Olingo, but Olingo is a REST controller so it has no nice way to
fit into spring. I'm going to see if I can latch into the part of Olingo
that deals with the OData syntax and reuse from there. But it looks like
it will be a dirty hack as Olingo seems to be both REST and JPA. Maybe I
could just redirect incoming requests to an Olingo controller. But that
will remove the point of using elasticsearch!!

I believe OData is something that is well supported in the .NET
framework but not that well supported in the java ecosystem (despite
Olingo existing). I created a olingo based project and will try and see
what I can do with it next week. I know i'm jumping a little into the
0.3 release with this, but I don't want to have do a big rewrite going
from 0.2 to 0.3 to deal with OData syntax

 - Tom