Embrace, extend and extinguish

[Thomas Sødring]

Hi,

The point Petter is making is that POST requests can use both Norwegian
and English language for field identifiers. GET requests only produce
Norwegian field names.

The  following illustrates this:

Part of a POST request for ny-arkiv, would according to the standard be:

{
 "tittel" : "arkiv tittel",
 "beskrivelse" : "arkivets beskrivelse"
}

The core supports this, but also supports English field names:

{
 "title" : "arkiv tittel",
 "description" : "arkivets beskrivelse"
}

The core also supports mixing:

{
 "title" : "arkiv tittel",
 "beskrivelse" : "arkivets beskrivelse"
}

This correctly, as Petter explains, is functionality that is not part of
the standard.

Why did this get introduced?  I need to use this as a teaching tool and
I have English
students. We tried working with Norwegian fieldnames, but it didn't
work. Somewhere via
google translate the term saksdokument, was translated as
scissorsdocument so I ended up
translating all metadata elements. I need a certain level of control
over how this is used.

I also believe the Noark standard should have been published in English.
A problem with a National standard like Noark if there is no proper
English translation is that we are at the mercy of the Norwegian vendors
who face no real competition. The investment into Noark is really high
so we need as much of this in English as possible. Now there is no
chance that Riksarkivet will ever commit to keeping documentation in
English alive, so my approach to allowing English means that English
speakers may also have a chance understanding Noark. It's about lowering
the barrier to entry.

On 03/12/2017 09:37 AM, Petter Reinholdtsen wrote:
> Is it really a good idea to accept several field names for the same
> object attribute when adding new object in Nikita?  Thomas mentioned on
> #nikita yesterday that the code accept both the norwegian attributes
> listed in the official specification, and english attribute names to
> make life easier for english speaking students.  Is this really a good
> idea?
Is it a good idea? Probably not. Based on our discussion today on
#nikita, no it will confuse people
>
> What should happen if a POST list both the norwegian and english
> attributes?  What if some attibutes are norwegian and the other are
> english?  Should mixing allowed?
Currently mixing is allowed. The Core does not care as long as it is
able to correctly identify the fieldname.

>
> I believe having multiple attribute names is going to cause
> compatibility problems and introduce unneeded bugs.
An example of such a bug is, how to handle the following
{
 "title" : "arkiv tittel",
 "beskrivelse" : "arkivets beskrivelse"
 "description" : "The archives description"
}

Currently the above is valid and the final one that is parsed,  "wins".
I guess a developer could may make an assumption that the core is
bi-lingual in such a case, and assume that both descriptions are being
stored.

>
> I am sure there are many good reasons to deviate from the specification,
> but every time we do so we make life harder for applications trying to
> talk to us over the documented protocol.  Is it really worth it for
> this?

Before Petter got involved, this project was just something that was to
be used as a teaching tool. And in the name of education I was willing
to do what had to be done!  Petter and Alexanders involvement have
really raised the project and shown the potential that this project
really may have usefulness outside of HiOA. I think the project has a
potential to be a good reference implementation, but then we need to
stick to the standard.

One of the things Petter does is to keep things "right". He watches
commits and raises questions if something seems off, asks questions why
things are they way they are. Sometimes I deviate and I guess it is
partially from being a "research" developer, not being a "professional"
developer. There is a good Norwegian expression for this situation -
"Lytt til erfarne fjellfolk".

Is it worth it? For teaching purposes? I guess not. I accept this point
and during the week I will  push out a commit that ensures only
Norwegian fieldnames are used.

 - Tom