Re: Announcing Archie version 0.4

[Bert Verhees]

On 23-02-18 17:17, Thomas Beale wrote:


On 23/02/2018 15:36, Pieter Bos wrote:
For microservices with enough traffic, or for devices with limited 
processing power or limited bandwidth, a binary encoding makes sense. 
However, GRPC would not be my first choice for OpenEHR - you would 
have to find a way to map all the inheritance in the OpenEHR model to 
protocol buffers.




actually, you don't need to do that, you can just map to protobuf from 
inheritance-flattened form of the model classes. That can easily be 
generated from a model - UML tools, do it, BMM supports it, I think it 
should also be easy via Java reflection.


Good idea, there is some information on the subject on internet.

Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Thomas Beale]

On 23/02/2018 15:36, Pieter Bos wrote:

For microservices with enough traffic, or for devices with limited processing 
power or limited bandwidth, a binary encoding makes sense. However, GRPC would 
not be my first choice for OpenEHR - you would have to find a way to map all 
the inheritance in the OpenEHR model to protocol buffers.



actually, you don't need to do that, you can just map to protobuf from 
inheritance-flattened form of the model classes. That can easily be 
generated from a model - UML tools, do it, BMM supports it, I think it 
should also be easy via Java reflection.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pieter Bos]

From the tutorial you mention:

'Don't go looking for facilities similar to class inheritance, though – 
protocol buffers don't do that.'

On 23/02/2018, 16:57, "openEHR-technical on behalf of Bert Verhees" 
 
wrote:

On 23-02-18 16:36, Pieter Bos wrote:
> you would have to find a way to map all the inheritance in the OpenEHR 
model to protocol buffers.
For Java I found this web-page which explains how to do it. It is about 
a class with one nested class

https://developers.google.com/protocol-buffers/docs/javatutorial




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Bert Verhees]

On 23-02-18 16:36, Pieter Bos wrote:

you would have to find a way to map all the inheritance in the OpenEHR model to 
protocol buffers.
For Java I found this web-page which explains how to do it. It is about 
a class with one nested class


https://developers.google.com/protocol-buffers/docs/javatutorial




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pieter Bos]

Those are all valid points, but for many applications, I would say are not 
actual problems. If we're discussing the context of archetype editing tools, I 
would say REST with JSON is fine. HTTP traffic is usually compressed and 
browsers have heavily optimized their JSON parsing, making it much more 
efficient than it would seem. Very good tools are available in many languages 
to parse and validate JSON encoded data against a given model and given types. 
Many people know how to use it so they can start developing right away, and 
debugging is easy due to the fact that is human readable.

For microservices with enough traffic, or for devices with limited processing 
power or limited bandwidth, a binary encoding makes sense. However, GRPC would 
not be my first choice for OpenEHR - you would have to find a way to map all 
the inheritance in the OpenEHR model to protocol buffers.

Regards,

Pieter Bos
Nedap Healthcare

On 23/02/2018, 15:30, "openEHR-technical on behalf of Bert Verhees" 
 
wrote:

On 23-02-18 14:37, Pieter Bos wrote:
> A small amount of JavaScript working with Json from a backend works very 
well for us.
>
> You don’t always need explicit class definitions. it does require a 
different programming style than a more object oriented language.

Thomas has a point,

JSON/REST is not efficient,
- text takes a lot of bandwidth, an Integer f.e. 3,000,000,000 is only 4 
bytes in binary but 10 bytes in text,
- the translating from datatypes to text and back again takes a lot of 
CPU cycles,
- semantical is REST not fitted for many function-calls, HTTP-errors are 
misused for functional error-codes
- the http-protocol with all the headers is not efficient and has 
unnecessary overload
- REST is not error or type safe, you can send anything to a 
restservice, it processes the whole request-headers, and then looks if 
the parameters are sufficient in number and in type

Check this, it is a good explanation (if you have time for that, it 
hardly handles about Go):
https://www.youtube.com/watch?v=J-NTfvYL_OE

The question is only of a license-restricted product as ICE is the 
answer to this problem
For microservices GRPC works very well, it has a performance of 
sometimes 100* the performance of rest, it supports also bi-directional 
streaming, and it is safe, because the interface-code is generated.

There are some promising projects for GRPC in browsers which support 
HTTP/2 (this are all browsers in their latest versions)
I did not test it, but I will, in a few weeks in a project I am working on.
https://github.com/improbable-eng/grpc-web

Bert

>
> Regards,
>
> Pieter Bos
>
> Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
mailto:bert.verh...@rosa.nl>> het volgende geschreven:
>
> The problem with Ice is that it is not open source licensed when used in 
a non GPLv2 product.
> Another problem is that they do not publish the price of a commercial 
license.
>
> That are restrictions that cause many programmers not to use it.
>
> https://zeroc.com/licensing
>
>
> On 23-02-18 13:59, Thomas Beale wrote:
>
> Belated thought on this topic: a much better way to connect a JavaScript 
front end with a Java back end, or any similar combination, would be with a 
binary RPC protocol like ICE, that comes with 
tools to make it all work.
>
> - thomas
>
> On 05/02/2018 22:04, Thomas Beale wrote:
>
>
> yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.
>
> - thomas
>
> On 03/02/2018 07:56, Peter Gummer wrote:
> On 1 Feb 2018, at 05:13, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:
>
> ... But the main interest is that we will be able to build new tools such 
as a Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.
>
> Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how 
Archie (written in Java, disappointingly) would enable JavaScript 
implementations. JavaScript has nothing in common with Java (apart from the 
name).
>
> Peter
>
>
>
>
> ___
> openEHR-technical mailing list
> 
openEHR-technical@lists.openehr.org
> 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> _

Re: Announcing Archie version 0.4

[Bert Verhees]

On 23-02-18 14:37, Pieter Bos wrote:

A small amount of JavaScript working with Json from a backend works very well 
for us.

You don’t always need explicit class definitions. it does require a different 
programming style than a more object oriented language.


Thomas has a point,

JSON/REST is not efficient,
- text takes a lot of bandwidth, an Integer f.e. 3,000,000,000 is only 4 
bytes in binary but 10 bytes in text,
- the translating from datatypes to text and back again takes a lot of 
CPU cycles,
- semantical is REST not fitted for many function-calls, HTTP-errors are 
misused for functional error-codes
- the http-protocol with all the headers is not efficient and has 
unnecessary overload
- REST is not error or type safe, you can send anything to a 
restservice, it processes the whole request-headers, and then looks if 
the parameters are sufficient in number and in type


Check this, it is a good explanation (if you have time for that, it 
hardly handles about Go):

https://www.youtube.com/watch?v=J-NTfvYL_OE

The question is only of a license-restricted product as ICE is the 
answer to this problem
For microservices GRPC works very well, it has a performance of 
sometimes 100* the performance of rest, it supports also bi-directional 
streaming, and it is safe, because the interface-code is generated.


There are some promising projects for GRPC in browsers which support 
HTTP/2 (this are all browsers in their latest versions)

I did not test it, but I will, in a few weeks in a project I am working on.
https://github.com/improbable-eng/grpc-web

Bert



Regards,

Pieter Bos

Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
mailto:bert.verh...@rosa.nl>> het volgende geschreven:

The problem with Ice is that it is not open source licensed when used in a non 
GPLv2 product.
Another problem is that they do not publish the price of a commercial license.

That are restrictions that cause many programmers not to use it.

https://zeroc.com/licensing


On 23-02-18 13:59, Thomas Beale wrote:

Belated thought on this topic: a much better way to connect a JavaScript front end 
with a Java back end, or any similar combination, would be with a binary RPC protocol 
like ICE, that comes with tools to make it all 
work.

- thomas

On 05/02/2018 22:04, Thomas Beale wrote:


yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. 
Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.

- thomas

On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

... But the main interest is that we will be able to build new tools such as a 
Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pieter Bos]

A small amount of JavaScript working with Json from a backend works very well 
for us.

You don’t always need explicit class definitions. it does require a different 
programming style than a more object oriented language.

Regards,

Pieter Bos

Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
mailto:bert.verh...@rosa.nl>> het volgende geschreven:

The problem with Ice is that it is not open source licensed when used in a non 
GPLv2 product.
Another problem is that they do not publish the price of a commercial license.

That are restrictions that cause many programmers not to use it.

https://zeroc.com/licensing


On 23-02-18 13:59, Thomas Beale wrote:

Belated thought on this topic: a much better way to connect a JavaScript front 
end with a Java back end, or any similar combination, would be with a binary 
RPC protocol like ICE, that comes with tools to 
make it all work.

- thomas

On 05/02/2018 22:04, Thomas Beale wrote:


yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. 
Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.

- thomas

On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

... But the main interest is that we will be able to build new tools such as a 
Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Bert Verhees]

The problem with Ice is that it is not open source licensed when used in 
a non GPLv2 product.
Another problem is that they do not publish the price of a commercial 
license.


That are restrictions that cause many programmers not to use it.

https://zeroc.com/licensing


On 23-02-18 13:59, Thomas Beale wrote:


Belated thought on this topic: a much better way to connect a 
JavaScript front end with a Java back end, or any similar combination, 
would be with a binary RPC protocol like ICE 
, that comes with tools to make it all 
work.


- thomas

On 05/02/2018 22:04, Thomas Beale wrote:



yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for 
web app development these days, and Java for the back-end. The 
connection between front and back-end that people seem to prefer 
these days is REST APIs, which both Java and JS can do easily enough.


- thomas


On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale > wrote:


... But the main interest is that we will be able to build new 
tools such as a Java/JS replacement for the ADL Workbench, and of 
course things like a high-quality, BMM-driven runtime archetype 
validating kernel for EHR systems, workflow implementations and 
many other components.




Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand 
how Archie (written in Java, disappointingly) would enable 
JavaScript implementations. JavaScript has nothing in common with 
Java (apart from the name).


Peter




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Thomas Beale]

Belated thought on this topic: a much better way to connect a JavaScript 
front end with a Java back end, or any similar combination, would be 
with a binary RPC protocol like ICE , 
that comes with tools to make it all work.


- thomas

On 05/02/2018 22:04, Thomas Beale wrote:



yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for 
web app development these days, and Java for the back-end. The 
connection between front and back-end that people seem to prefer these 
days is REST APIs, which both Java and JS can do easily enough.


- thomas


On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale > wrote:


... But the main interest is that we will be able to build new tools 
such as a Java/JS replacement for the ADL Workbench, and of course 
things like a high-quality, BMM-driven runtime archetype validating 
kernel for EHR systems, workflow implementations and many other 
components.




Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand 
how Archie (written in Java, disappointingly) would enable JavaScript 
implementations. JavaScript has nothing in common with Java (apart 
from the name).


Peter


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Thomas Beale]

yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for 
web app development these days, and Java for the back-end. The 
connection between front and back-end that people seem to prefer these 
days is REST APIs, which both Java and JS can do easily enough.


- thomas


On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale > wrote:


... But the main interest is that we will be able to build new tools 
such as a Java/JS replacement for the ADL Workbench, and of course 
things like a high-quality, BMM-driven runtime archetype validating 
kernel for EHR systems, workflow implementations and many other 
components.




Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand 
how Archie (written in Java, disappointingly) would enable JavaScript 
implementations. JavaScript has nothing in common with Java (apart 
from the name).


Peter



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Erik Sundvall]

Great work! A very good contribution both as code (with widely usable
licence) and in practice as a specification debugging effort!

//Erik Sundvall

P.s. Regarding Javascript I’d recommend looking at the related Typescript
superset instead for anybody wanting to do implement openEHR RM or AM on
client side in browsers. It will  likely feel more familiar for Java (and
Eiffel) people and others wanting to do generics, type checking etc.

Is anybody out there working on or planning a Typescript (or possibly
JavaScript) based openEHR library implementation with a permissive open
source licence (like Apache 2)? I guess many thoughts and design patterns
from Archie could be reused... Such a library could be used for e.g.
https://angular.io/ and/or https://nodejs.org/en/ based projects.



lör 3 feb. 2018 kl. 22:12 skrev Peter Gummer :

> Interaction with a JavaScript front-end could be done with any back-end
> programming language — it doesn’t have to be Java.
>
> So your point is that Archie's serialisation and deserialisation to JSON
> will will assist this? I believe Thomas’s Eiffel implementation already has
> JSON serialisation, since about 5 years ago.
>
> Peter
>
>
> > On 3 Feb 2018, at 23:03, Pieter Bos  wrote:
> >
> > Or a Java app with rest api and a JavaScript frontend. Let the java
> application take care of parsing, validating, flattening, operational
> template creation etc and send json to your front end. Archie has built-in
> json serialization and deserialization support.
> >
> > Pieter
> >
> > Op 3 feb. 2018 om 12:05 heeft Seref Arikan <
> serefari...@kurumsalteknoloji.com>
> het volgende geschreven:
> >
> > Hi Peter,
> >
> > Presumably via use of a transpiler or a bytecode to js/webassembly
> compiler.
> >
> > On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer  > wrote:
> > On 1 Feb 2018, at 05:13, Thomas Beale  thomas.be...@openehr.org>> wrote:
> >
> > ... But the main interest is that we will be able to build new tools
> such as a Java/JS replacement for the ADL Workbench, and of course things
> like a high-quality, BMM-driven runtime archetype validating kernel for EHR
> systems, workflow implementations and many other components.
> >
> > Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how
> Archie (written in Java, disappointingly) would enable JavaScript
> implementations. JavaScript has nothing in common with Java (apart from the
> name).
> >
> > Peter
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- 
Sent from mobile.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Peter Gummer]

Interaction with a JavaScript front-end could be done with any back-end 
programming language — it doesn’t have to be Java.

So your point is that Archie's serialisation and deserialisation to JSON will 
will assist this? I believe Thomas’s Eiffel implementation already has JSON 
serialisation, since about 5 years ago.

Peter


> On 3 Feb 2018, at 23:03, Pieter Bos  wrote:
> 
> Or a Java app with rest api and a JavaScript frontend. Let the java 
> application take care of parsing, validating, flattening, operational 
> template creation etc and send json to your front end. Archie has built-in 
> json serialization and deserialization support.
> 
> Pieter
> 
> Op 3 feb. 2018 om 12:05 heeft Seref Arikan 
> mailto:serefari...@kurumsalteknoloji.com>> 
> het volgende geschreven:
> 
> Hi Peter,
> 
> Presumably via use of a transpiler or a bytecode to js/webassembly compiler.
> 
> On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer 
> mailto:peter.gum...@gmail.com>> wrote:
> On 1 Feb 2018, at 05:13, Thomas Beale 
> mailto:thomas.be...@openehr.org>> wrote:
> 
> ... But the main interest is that we will be able to build new tools such as 
> a Java/JS replacement for the ADL Workbench, and of course things like a 
> high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
> workflow implementations and many other components.
> 
> Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how 
> Archie (written in Java, disappointingly) would enable JavaScript 
> implementations. JavaScript has nothing in common with Java (apart from the 
> name).
> 
> Peter


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pablo Pazos]

Thanks Pieter, I'm sure we will use it when adl 2 time arrive for us, we
are still on 1.4.

On Feb 3, 2018 9:04 AM, "Pieter Bos"  wrote:

Or a Java app with rest api and a JavaScript frontend. Let the java
application take care of parsing, validating, flattening, operational
template creation etc and send json to your front end. Archie has built-in
json serialization and deserialization support.

Pieter

Op 3 feb. 2018 om 12:05 heeft Seref Arikan mailto:serefari...@kurumsalteknoloji.com>> het
volgende geschreven:

Hi Peter,

Presumably via use of a transpiler or a bytecode to js/webassembly compiler.

On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer mailto:peter.gum...@gmail.com>> wrote:
On 1 Feb 2018, at 05:13, Thomas Beale > wrote:

... But the main interest is that we will be able to build new tools such
as a Java/JS replacement for the ADL Workbench, and of course things like a
high-quality, BMM-driven runtime archetype validating kernel for EHR
systems, workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how
Archie (written in Java, disappointingly) would enable JavaScript
implementations. JavaScript has nothing in common with Java (apart from the
name).

Peter


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-
technical_lists.openehr.org

___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-
implementers_lists.openehr.org
___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-
implementers_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pieter Bos]

Or a Java app with rest api and a JavaScript frontend. Let the java application 
take care of parsing, validating, flattening, operational template creation etc 
and send json to your front end. Archie has built-in json serialization and 
deserialization support.

Pieter

Op 3 feb. 2018 om 12:05 heeft Seref Arikan 
mailto:serefari...@kurumsalteknoloji.com>> 
het volgende geschreven:

Hi Peter,

Presumably via use of a transpiler or a bytecode to js/webassembly compiler.

On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer 
mailto:peter.gum...@gmail.com>> wrote:
On 1 Feb 2018, at 05:13, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

... But the main interest is that we will be able to build new tools such as a 
Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Seref Arikan]

Hi Peter,

Presumably via use of a transpiler or a bytecode to js/webassembly
compiler.

On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer 
wrote:

> On 1 Feb 2018, at 05:13, Thomas Beale  wrote:
>
> ... But the main interest is that we will be able to build new tools such
> as a Java/JS replacement for the ADL Workbench, and of course things like a
> high-quality, BMM-driven runtime archetype validating kernel for EHR
> systems, workflow implementations and many other components.
>
>
> Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how
> Archie (written in Java, disappointingly) would enable JavaScript
> implementations. JavaScript has nothing in common with Java (apart from the
> name).
>
> Peter
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Peter Gummer]

On 1 Feb 2018, at 05:13, Thomas Beale  wrote:
> ... But the main interest is that we will be able to build new tools such as 
> a Java/JS replacement for the ADL Workbench, and of course things like a 
> high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
> workflow implementations and many other components.
> 

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pieter Bos]

And due to several small bugs, we’re at version 0.4.2. Should be available soon 
at maven central.

For anyone wanting to test Archie without writing code, we’ve also created a 
command-line archetype validator. Works with all included BMM reference models, 
including OpenEHR and CIMI.

To use:

1.   Download adlchecker.zip version 0.4.2 from the releases page of the 
archie github repository, at https://github.com/openEHR/archie/releases.

2.   Unzip

3.   Make sure you have a java 8 JRE installed and that typing ‘java 
-version’ in a command/terminal window shows you installed java version 1.8.x

4.   Run bin/adlchecker (linux, OS X) or bin/adlchecker.bat (windows) from 
a terminal/command prompt and follow the instructions to point it at your 
archetypes

Note that it only supports ADL 2, not 1.4. It can also output the flat ADL.

If you find any issues, they can be reported at the github repository.

Regards,

Pieter Bos
Nedap Healthcare

From: openEHR-technical  on behalf 
of Thomas Beale 
Reply-To: For openEHR technical discussions 

Date: Wednesday, 31 January 2018 at 19:13
To: "openehr-implement...@lists.openehr.org" 
, Openehr-Technical 

Subject: Re: Announcing Archie version 0.4




This is excellent work, and has proven to be a great test for the AM 
specifications<http://www.openehr.org/releases/AM/latest/docs/index>, helping 
me to find various errors. But the main interest is that we will be able to 
build new tools such as a Java/JS replacement for the ADL Workbench, and of 
course things like a high-quality, BMM-driven runtime archetype validating 
kernel for EHR systems, workflow implementations and many other components.
- thomas
On 31/01/2018 15:18, Pieter Bos wrote:

Hi,



We’re pleased to announce Archie version 0.4! For those of you unfamiliar with 
Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for 
archetype modelling and EHR implementations with ADL 2.



Version 0.4 is a big change from version 0.3. Many features have been added 
that make Archie suitable as a library for modelling archetypes, and the 
existing functionality has been improved.



It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle and 
Kurt Allen. This enables Archie to work with other reference models than the 
included OpenEHR reference model. The BMM files and AOM profiles that are in 
the ADL workbench are included in the library – of course you can supply your 
own as well.



We developed an archetype validator that implements nearly all of the 
validations in the specification, and we improved the flattener and the 
operational template creator to be compliant with the specifications. The 
flattener, archetype validator and operational template creator work with both 
the BMM models or with metadata derived from an actual java reference model 
implementation.

Many tests were added to ensure better conformance with the specification and 
many fixes have been introduced. We’d like to thank Thomas Beale for giving 
advice about many details of the working of OpenEHR implementations and for 
fixing mistakes in the specifications when they were found.



Of course, Archie also contains a lot of other tools, many of which allow it to 
be used as the basis for an EHR implementation as well as a modelling tool: An 
ADL parser and serializer, the OpenEHR reference models, rule evaluation, path 
lookup, JSON and XML (de)serialization, ODIN parsing and RM object manipulation 
tools.



Archie version 0.4.1 is available at Maven Central. See the instructions and 
documentation in the readme at https://github.com/openehr/archie for how to use 
the library.



Regards,



Pieter Bos

Nedap Healthcare

___

openEHR-implementers mailing list

openehr-implement...@lists.openehr.org<mailto:openehr-implement...@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Team, Intermountain 
Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR 
Foundation<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer 
Society<http://www.bcs.org/category/6044>
Health IT blog<http://wolandscat.net/> | Culture 
blog<http://wolandsothercat.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Thomas Beale]

This is excellent work, and has proven to be a great test for the AM 
specifications , 
helping me to find various errors. But the main interest is that we will 
be able to build new tools such as a Java/JS replacement for the ADL 
Workbench, and of course things like a high-quality, BMM-driven runtime 
archetype validating kernel for EHR systems, workflow implementations 
and many other components.


- thomas

On 31/01/2018 15:18, Pieter Bos wrote:

Hi,

We’re pleased to announce Archie version 0.4! For those of you unfamiliar with 
Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for 
archetype modelling and EHR implementations with ADL 2.

Version 0.4 is a big change from version 0.3. Many features have been added 
that make Archie suitable as a library for modelling archetypes, and the 
existing functionality has been improved.

It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle and 
Kurt Allen. This enables Archie to work with other reference models than the 
included OpenEHR reference model. The BMM files and AOM profiles that are in 
the ADL workbench are included in the library – of course you can supply your 
own as well.

We developed an archetype validator that implements nearly all of the 
validations in the specification, and we improved the flattener and the 
operational template creator to be compliant with the specifications. The 
flattener, archetype validator and operational template creator work with both 
the BMM models or with metadata derived from an actual java reference model 
implementation.
Many tests were added to ensure better conformance with the specification and 
many fixes have been introduced. We’d like to thank Thomas Beale for giving 
advice about many details of the working of OpenEHR implementations and for 
fixing mistakes in the specifications when they were found.

Of course, Archie also contains a lot of other tools, many of which allow it to 
be used as the basis for an EHR implementation as well as a modelling tool: An 
ADL parser and serializer, the OpenEHR reference models, rule evaluation, path 
lookup, JSON and XML (de)serialization, ODIN parsing and RM object manipulation 
tools.

Archie version 0.4.1 is available at Maven Central. See the instructions and 
documentation in the readme at https://github.com/openehr/archie for how to use 
the library.

Regards,

Pieter Bos
Nedap Healthcare
___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[William Archibald]

This is great! Thank you!

On Wed, Jan 31, 2018 at 9:18 AM, Pieter Bos  wrote:

> Hi,
>
> We’re pleased to announce Archie version 0.4! For those of you unfamiliar
> with Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a
> basis for archetype modelling and EHR implementations with ADL 2.
>
> Version 0.4 is a big change from version 0.3. Many features have been
> added that make Archie suitable as a library for modelling archetypes, and
> the existing functionality has been improved.
>
> It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle
> and Kurt Allen. This enables Archie to work with other reference models
> than the included OpenEHR reference model. The BMM files and AOM profiles
> that are in the ADL workbench are included in the library – of course you
> can supply your own as well.
>
> We developed an archetype validator that implements nearly all of the
> validations in the specification, and we improved the flattener and the
> operational template creator to be compliant with the specifications. The
> flattener, archetype validator and operational template creator work with
> both the BMM models or with metadata derived from an actual java reference
> model implementation.
> Many tests were added to ensure better conformance with the specification
> and many fixes have been introduced. We’d like to thank Thomas Beale for
> giving advice about many details of the working of OpenEHR implementations
> and for fixing mistakes in the specifications when they were found.
>
> Of course, Archie also contains a lot of other tools, many of which allow
> it to be used as the basis for an EHR implementation as well as a modelling
> tool: An ADL parser and serializer, the OpenEHR reference models, rule
> evaluation, path lookup, JSON and XML (de)serialization, ODIN parsing and
> RM object manipulation tools.
>
> Archie version 0.4.1 is available at Maven Central. See the instructions
> and documentation in the readme at https://github.com/openehr/archie for
> how to use the library.
>
> Regards,
>
> Pieter Bos
> Nedap Healthcare
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Bert Verhees]

Thanks, Pieter, very useful, good work

Best regards
Bert


On 31-01-18 16:18, Pieter Bos wrote:

Hi,

We’re pleased to announce Archie version 0.4! For those of you unfamiliar with 
Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for 
archetype modelling and EHR implementations with ADL 2.

Version 0.4 is a big change from version 0.3. Many features have been added 
that make Archie suitable as a library for modelling archetypes, and the 
existing functionality has been improved.

It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle and 
Kurt Allen. This enables Archie to work with other reference models than the 
included OpenEHR reference model. The BMM files and AOM profiles that are in 
the ADL workbench are included in the library – of course you can supply your 
own as well.

We developed an archetype validator that implements nearly all of the 
validations in the specification, and we improved the flattener and the 
operational template creator to be compliant with the specifications. The 
flattener, archetype validator and operational template creator work with both 
the BMM models or with metadata derived from an actual java reference model 
implementation.
Many tests were added to ensure better conformance with the specification and 
many fixes have been introduced. We’d like to thank Thomas Beale for giving 
advice about many details of the working of OpenEHR implementations and for 
fixing mistakes in the specifications when they were found.

Of course, Archie also contains a lot of other tools, many of which allow it to 
be used as the basis for an EHR implementation as well as a modelling tool: An 
ADL parser and serializer, the OpenEHR reference models, rule evaluation, path 
lookup, JSON and XML (de)serialization, ODIN parsing and RM object manipulation 
tools.

Archie version 0.4.1 is available at Maven Central. See the instructions and 
documentation in the readme at https://github.com/openehr/archie for how to use 
the library.

Regards,

Pieter Bos
Nedap Healthcare
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Ian McNicoll]

Hi Pieter,

Can I also express my thanks on behalf of the openEHR community.  Late in
life I am becoming a bit of a java-ninja (well , in my dreams), so I will
definitely give Archie a go. I can already think of a few really useful
bits of tooling we could develop.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 31 January 2018 at 15:32, Seref Arikan  wrote:

> Pieter,
>
> Allow me to express my appreciation and gratitude please: Archie is a
> fantastic piece of work, which has become my go-to library since I
> discovered it. Thanks a lot for all your hard work.
>
> Kind regards
> Seref
>
>
> On Wed, Jan 31, 2018 at 3:18 PM, Pieter Bos  wrote:
>
>> Hi,
>>
>> We’re pleased to announce Archie version 0.4! For those of you unfamiliar
>> with Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a
>> basis for archetype modelling and EHR implementations with ADL 2.
>>
>> Version 0.4 is a big change from version 0.3. Many features have been
>> added that make Archie suitable as a library for modelling archetypes, and
>> the existing functionality has been improved.
>>
>> It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle
>> and Kurt Allen. This enables Archie to work with other reference models
>> than the included OpenEHR reference model. The BMM files and AOM profiles
>> that are in the ADL workbench are included in the library – of course you
>> can supply your own as well.
>>
>> We developed an archetype validator that implements nearly all of the
>> validations in the specification, and we improved the flattener and the
>> operational template creator to be compliant with the specifications. The
>> flattener, archetype validator and operational template creator work with
>> both the BMM models or with metadata derived from an actual java reference
>> model implementation.
>> Many tests were added to ensure better conformance with the specification
>> and many fixes have been introduced. We’d like to thank Thomas Beale for
>> giving advice about many details of the working of OpenEHR implementations
>> and for fixing mistakes in the specifications when they were found.
>>
>> Of course, Archie also contains a lot of other tools, many of which allow
>> it to be used as the basis for an EHR implementation as well as a modelling
>> tool: An ADL parser and serializer, the OpenEHR reference models, rule
>> evaluation, path lookup, JSON and XML (de)serialization, ODIN parsing and
>> RM object manipulation tools.
>>
>> Archie version 0.4.1 is available at Maven Central. See the instructions
>> and documentation in the readme at https://github.com/openehr/archie for
>> how to use the library.
>>
>> Regards,
>>
>> Pieter Bos
>> Nedap Healthcare
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Seref Arikan]

Pieter,

Allow me to express my appreciation and gratitude please: Archie is a
fantastic piece of work, which has become my go-to library since I
discovered it. Thanks a lot for all your hard work.

Kind regards
Seref


On Wed, Jan 31, 2018 at 3:18 PM, Pieter Bos  wrote:

> Hi,
>
> We’re pleased to announce Archie version 0.4! For those of you unfamiliar
> with Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a
> basis for archetype modelling and EHR implementations with ADL 2.
>
> Version 0.4 is a big change from version 0.3. Many features have been
> added that make Archie suitable as a library for modelling archetypes, and
> the existing functionality has been improved.
>
> It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle
> and Kurt Allen. This enables Archie to work with other reference models
> than the included OpenEHR reference model. The BMM files and AOM profiles
> that are in the ADL workbench are included in the library – of course you
> can supply your own as well.
>
> We developed an archetype validator that implements nearly all of the
> validations in the specification, and we improved the flattener and the
> operational template creator to be compliant with the specifications. The
> flattener, archetype validator and operational template creator work with
> both the BMM models or with metadata derived from an actual java reference
> model implementation.
> Many tests were added to ensure better conformance with the specification
> and many fixes have been introduced. We’d like to thank Thomas Beale for
> giving advice about many details of the working of OpenEHR implementations
> and for fixing mistakes in the specifications when they were found.
>
> Of course, Archie also contains a lot of other tools, many of which allow
> it to be used as the basis for an EHR implementation as well as a modelling
> tool: An ADL parser and serializer, the OpenEHR reference models, rule
> evaluation, path lookup, JSON and XML (de)serialization, ODIN parsing and
> RM object manipulation tools.
>
> Archie version 0.4.1 is available at Maven Central. See the instructions
> and documentation in the readme at https://github.com/openehr/archie for
> how to use the library.
>
> Regards,
>
> Pieter Bos
> Nedap Healthcare
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Announcing Archie version 0.4

[Pieter Bos]

Hi,

We’re pleased to announce Archie version 0.4! For those of you unfamiliar with 
Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for 
archetype modelling and EHR implementations with ADL 2.

Version 0.4 is a big change from version 0.3. Many features have been added 
that make Archie suitable as a library for modelling archetypes, and the 
existing functionality has been improved.

It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle and 
Kurt Allen. This enables Archie to work with other reference models than the 
included OpenEHR reference model. The BMM files and AOM profiles that are in 
the ADL workbench are included in the library – of course you can supply your 
own as well.

We developed an archetype validator that implements nearly all of the 
validations in the specification, and we improved the flattener and the 
operational template creator to be compliant with the specifications. The 
flattener, archetype validator and operational template creator work with both 
the BMM models or with metadata derived from an actual java reference model 
implementation.
Many tests were added to ensure better conformance with the specification and 
many fixes have been introduced. We’d like to thank Thomas Beale for giving 
advice about many details of the working of OpenEHR implementations and for 
fixing mistakes in the specifications when they were found.

Of course, Archie also contains a lot of other tools, many of which allow it to 
be used as the basis for an EHR implementation as well as a modelling tool: An 
ADL parser and serializer, the OpenEHR reference models, rule evaluation, path 
lookup, JSON and XML (de)serialization, ODIN parsing and RM object manipulation 
tools.

Archie version 0.4.1 is available at Maven Central. See the instructions and 
documentation in the readme at https://github.com/openehr/archie for how to use 
the library.

Regards,

Pieter Bos
Nedap Healthcare
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org