<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p><br>
</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> nikita-noark-bounces@nuug.no <nikita-noark-bounces@nuug.no> on behalf of Petter Reinholdtsen <pere@hungry.com><br>
<b>Sent:</b> Wednesday, May 24, 2017 00:25<br>
<b>To:</b> nikita-noark@nuug.no<br>
<b>Subject:</b> Re: How to know the class of an entity?</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
[Thomas Sødring]<br>
> So it is possible to filter out saksmappe.<br>
<i><br>
We seem to be making different assumtions. I assume the only class<br>
names / identifiers a API client can depend on is the value of the rel<br>
attribute, while you seem to assume a specific structure of the value of<br>
the href attribute. As far as I can tell from the spec, this is also <br>
valid _links content of a conforming implementation, without any<br>
identifying parts in href:<br>
<br>
rel : <a href="http://rel.kxml.no/noark5/v4/api/sakarkiv/saksmappe/" id="LPlnk563805" previewremoved="true">
http://rel.kxml.no/noark5/v4/api/sakarkiv/saksmappe/</a><br>
<br>
href : <a href="http://localhost:8092/a/b/c/1d7610f4-9bb0-4044-959d-4e79ab86a228/" id="LPlnk313916" previewremoved="true">
http://localhost:8092/a/b/c/1d7610f4-9bb0-4044-959d-4e79ab86a228/</a><br>
<br>
There is nothing in the spec that specify what the content of the href<br>
should look like. Thus I wonder how a client depending on what is<br>
dokumented in the specification can figure out what the class of a given<br>
entity is. And for this, I believe class type must be derived from the<br>
rel values, not the href values. Do you agree?</i></div>
<div class="PlainText"><br>
</div>
<div class="PlainText">I agree, the rel values are governed by the interface standard, the href</div>
<div class="PlainText">can be anything.<br>
<br>
<i>This is the background for my idea of using duplicate hrefs with 'self'<br>
and the class name in rel, ie something like this:<br>
<br>
rel : <a href="http://rel.kxml.no/noark5/v4/api/sakarkiv/saksmappe/" id="LPlnk631045" previewremoved="true">
http://rel.kxml.no/noark5/v4/api/sakarkiv/saksmappe/</a><br>
<br>
href : <a href="http://localhost:8092/a/b/c/1d7610f4-9bb0-4044-959d-4e79ab86a228/" id="LPlnk329611" previewremoved="true">
http://localhost:8092/a/b/c/1d7610f4-9bb0-4044-959d-4e79ab86a228/</a><br>
<br>
rel : self<br>
href : <a href="http://localhost:8092/a/b/c/1d7610f4-9bb0-4044-959d-4e79ab86a228/" id="LPlnk331474" previewremoved="true">
http://localhost:8092/a/b/c/1d7610f4-9bb0-4044-959d-4e79ab86a228/</a><br>
<br>
I believe this approach would work, but is there some other way to<br>
determine the class of a entity that is dokumented in the spec?<br>
</i><br>
Not that I am aware of, but there are multiple approaches that we could take.</div>
<div class="PlainText">There is also an OData approach where I believe the entity is identified. This means</div>
<div class="PlainText">the real entity is embedded in an outer entity. Can't remember the syntax, but it's </div>
<div class="PlainText">something like this.</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">{</div>
<div class="PlainText">"entity": korrespondansepartperson</div>
<div class="PlainText">{</div>
<div class="PlainText"> ......</div>
<div class="PlainText">}</div>
<div class="PlainText">}</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">I believe this is the way OData handles inheritance and one of the reasons</div>
<div class="PlainText">why I wrote the mangelmelding <span>2017-05-22-korrespondansepart-arv.md</span></div>
<div class="PlainText"><span>to avoid them introducing that method. I don't mention the OData approach </span></div>
<div class="PlainText"><span>in the mangelmelding, just ask RA </span><span style="font-size: 10pt;">to do it differently.</span></div>
<div class="PlainText"><i><br>
> We do however still need to be able to just retrieve saksmappe from<br>
> arkivdel.<br>
<br>
Yes. The lack of a way to get the saksmappe entities is blocking the<br>
postliste.html client from getting access to the journalpost metadata.<br>
Would love to have this in place. :)<br>
</i><br>
I was looking at it last night. I am testing a solution that I'm a little</div>
<div class="PlainText">unsure will work. If it does I'll push it later.</div>
<div class="PlainText"><br>
<i>I would also like the client to depend on what is documented in the<br>
spec, as much as possible.<br>
</i><br>
I agree! You have put in so much effort to ensure that we are in compliance<br>
</div>
<div class="PlainText">so we really should not deviate, except where it is unclear! And then we document!</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">The update CorrespondencePart is still not ready to roll I'm afraid. All the code</div>
<div class="PlainText">is in place, but there are a few wrinkles left to iron out.</div>
<div class="PlainText"><br>
</div>
<div class="PlainText"> - Tom</div>
</span></font></div>
</div>
</body>
</html>