How to know the class of an entity?

[Thomas Sødring]

________________________________
From: nikita-noark-bounces at nuug.no <nikita-noark-bounces at nuug.no> on behalf of Petter Reinholdtsen <pere at hungry.com>
Sent: Wednesday, May 24, 2017 00:25
To: nikita-noark at nuug.no
Subject: Re: How to know the class of an entity?


[Thomas Sødring]
> So it is possible to filter out saksmappe.

We seem to be making different assumtions.  I assume the only class
names / identifiers a API client can depend on is the value of the rel
attribute, while you seem to assume a specific structure of the value of
the href attribute.  As far as I can tell from the spec, this is also
valid _links content of a conforming implementation, without any
identifying parts in href:

  rel : http://rel.kxml.no/noark5/v4/api/sakarkiv/saksmappe/

  href : http://localhost:8092/a/b/c/1d7610f4-9bb0-4044-959d-4e79ab86a228/

There is nothing in the spec that specify what the content of the href
should look like.  Thus I wonder how a client depending on what is
dokumented in the specification can figure out what the class of a given
entity is.  And for this, I believe class type must be derived from the
rel values, not the href values.  Do you agree?

I agree, the rel values are governed by the interface standard, the href
can be anything.

This is the background for my idea of using duplicate hrefs with 'self'
and the class name in rel, ie something like this:

  rel : http://rel.kxml.no/noark5/v4/api/sakarkiv/saksmappe/

  href : http://localhost:8092/a/b/c/1d7610f4-9bb0-4044-959d-4e79ab86a228/

  rel : self
  href : http://localhost:8092/a/b/c/1d7610f4-9bb0-4044-959d-4e79ab86a228/

I believe this approach would work, but is there some other way to
determine the class of a entity that is dokumented in the spec?

Not that I am aware of, but there are multiple approaches that we could take.
There is also an OData approach where I believe the entity is identified. This means
the real entity is embedded in an outer entity. Can't remember the syntax, but it's
something like this.

{
"entity": korrespondansepartperson
{
 ......
}
}

I believe this is the way OData handles inheritance and one of the reasons
why I wrote the mangelmelding 2017-05-22-korrespondansepart-arv.md
to avoid them introducing that method. I don't mention the OData approach
in the mangelmelding, just ask RA to do it differently.

> We do however still need to be able to just retrieve saksmappe from
> arkivdel.

Yes.  The lack of a way to get the saksmappe entities is blocking the
postliste.html client from getting access to the journalpost metadata.
Would love to have this in place. :)

I was looking at it last night. I am testing a solution that I'm a little
unsure will work. If it does I'll push it later.

I would also like the client to depend on what is documented in the
spec, as much as possible.

I agree! You have put in so much effort to ensure that we are in compliance
so we really should not deviate, except where it is unclear! And then we document!

The update CorrespondencePart is still not ready to roll I'm afraid. All the code
is in place, but there are a few wrinkles left to iron out.

 - Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.nuug.no/pipermail/nikita-noark/attachments/20170524/01176379/attachment.htm