+1 this makes sense, though we retrofitted OMG RLUS onto FHIR, rather than it being our logical basis. But we simplified it a lot. Still, following the same pattern would make sense.
Grahame On Wed, Jan 21, 2015 at 9:22 AM, Heath Frankel < heath.frankel at oceaninformatics.com> wrote: > I too have looked how the approach used by FHIR could be applied > generically to openEHR, but at the entry level using TDDs. I actually went > up one level and considered the principals of the HL7-OMG RLUS > specification, which is the logical basis of FHIR before they hard coded > the resources. RLUS also has a SOAP based interface. > > The spec I wrote for this is being consider for implementation by three > vendors as part of a single project, they chose the SOAP binding rather > than REST (REST is not for everyone). Will be interesting if it happens. > > Regards > > Heath > > > On 19 Jan 2015, at 9:00 pm, "Diego Bosc?" <yampeku at gmail.com> wrote: > > > > I will just add that if you are making a server you probably want to > > take a look and how FHIR does things. They have some pretty cool ideas > > for common problems that you can probably reuse (e.g. using atom for > > query responses) > > > > 2015-01-19 11:25 GMT+01:00 Seref Arikan < > serefarikan at kurumsalteknoloji.com>: > >> I've managed not to respond for some time but this discussion got to a > point > >> where I can't help commenting :) > >> > >> REST is a fact of the industry, due to whatever mysterious dynamics that > >> pushes various solutions down our throat as we get old in front of our > >> computers. So we live with it. > >> > >> This does not change the fact that trying to push complex shaped objects > >> through a few holes shaped as a rectangle, circle and a triangle will > leave > >> some parts of those objects broken. Then we have people discussing for > ages > >> what the right verb mapping would be for an operation. If you try to > express > >> an infinite number of API calls and their semantics with a bunch of HTTP > >> operations and status codes, this is what you get. > >> > >> REST may make things easy for some use cases, but do complex use cases > in > >> healthcare fall into that category? I should probably look at Erik's > >> research at one point but my dislike for being forced to express > semantics > >> with a very limited number of some text transfer protocol based concepts > >> will not go away. > >> > >> Best regards > >> Seref > >> > >> > >>> On Mon, Jan 19, 2015 at 5:59 AM, Bert Verhees <bert.verhees at rosa.nl> > wrote: > >>> > >>> I checked on how the large companies like Google, Amazon, PayPal, > github > >>> do it. > >>> > >>> They all have a hybrid solution. They all use an own error schema was > >>> verbal terms, sometimes hierarchical, and they all map their errors to > the > >>> http numerical status schema. > >>> > >>> This means that a query with no result is qualified as a 404 error. > >>> However this seems unlogical to me, is that how the big guys it do. It > is > >>> the same error which is fired when you try to call a non existing > method. > >>> But the accompanying message is different. > >>> > >>> It is difficult for me to qualify a query which has no result as an > error. > >>> Have you ever been sick? No? That is a 404 error. > >>> > >>> But on the other hand, that is how the big guys do it. > >>> > >>> Bert > >>> > >>> Op maandag 19 januari 2015 heeft Bert Verhees <bert.verhees at rosa.nl> > het > >>> volgende geschreven: > >>> > >>>> Ok, you are right, but http is a very generic application layer, not > to > >>>> designed to serve specific application needs, but designed to serve > web > >>>> servers which only serve documents. > >>>> As you know, a web server is a very generic application, which, from > the > >>>> time Http was designed, was only recource driven. > >>>> > >>>> Maybe the error is that Rest uses a generic application layer which is > >>>> defined as a resource driven application layer, but in fact Rest is > used as > >>>> a service oriented application protocol. I think that an OpenEhr > kernel, or > >>>> PayPal-service, or many other Rest using applications are also service > >>>> oriented, not only resource oriented, and that therefor, a resource > oriented > >>>> error handling is unable to serve the needs of a service oriented > >>>> application. > >>>> > >>>> You could call that misusing http, because it was not designed for > that, > >>>> but on the other hand, with some new thinking, Http can be used to > serve a > >>>> service oriented architecture. Or do you not agree with this > statement? > >>>> > >>>> By the way, nowhere is written that Rest must use the Http status > >>>> mechanism for communicating application needs. It is written that > Rest must > >>>> used http statuses for http-needs, and Restlet does do that. > >>>> > >>>> best regards > >>>> Bert > >>>> > >>>> Op maandag 19 januari 2015 heeft Peter Gummer > >>>> <peter.gummer at oceaninformatics.com> het volgende geschreven: > >>>>> > >>>>> Bert Verhees wrote: > >>>>> > >>>>>> The point for me is separation of transport layer and application > >>>>>> layer, and each domain has its own errorhandling. > >>>>> > >>>>> > >>>>> > >>>>> Hi Bert, > >>>>> > >>>>> HTTP is not a transport layer protocol: > >>>>> > >>>>> http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol > >>>>> > >>>>> ?The Hypertext Transfer Protocol (HTTP) is an application protocol ?" > >>>>> > >>>>> Thanks for the discussion, though. I?ve learned a lot from it. > >>>>> > >>>>> Peter > >>>> > >>>> > >>>> > >>>> -- > >>>> This e-mail message is intended exclusively for the addressee(s). > >>>> Please inform us immediately if you are not the addressee. > >>> > >>> > >>> -- > >>> This e-mail message is intended exclusively for the addressee(s). > >>> Please inform us immediately if you are not the addressee. > >>> > >>> > >>> _______________________________________________ > >>> openEHR-technical mailing list > >>> openEHR-technical at lists.openehr.org > >>> > >>> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > >> > >> > >> > >> _______________________________________________ > >> openEHR-technical mailing list > >> openEHR-technical at lists.openehr.org > >> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at lists.openehr.org > > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- ----- http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150127/901fa497/attachment.html>
