Hey that?s really awesome!
Cheers,
-koray
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On
Behalf Of Roger Erens
Sent: Saturday, 13 April 2013 11:44 a.m.
To: For openEHR technical discussions
Subject: Re: openEHR Subversion = Github move progress
Hey
Bert Verhees wrote:
And of course, good non-GUI-building archetype-editors which are still not
there, the complains I had about the both mainstream archetype-editors were
admitted, but the improvement did not yet come.
Hi Bert,
I remember that you described some inconsistencies on one of
I am always somewhat surprised as well. Thanks by the way for your
clarifying notes, that is exactly how I would summarise the discussions.
- thomas
On 07/04/2013 22:08, Randolph Neall wrote:
Hi Thomas,
I'm surprised that at this advanced stage of openEHR's maturity you'd
still have to
There is always a meta-architecture. It's just a question of whether
system builders are conscious of it.
Thomas, perhaps you don't intend humor, but gems like this are what make
reading your posts both enlightening and entertaining, even for someone at
my distance.
On Mon, Apr 8, 2013 at 8:06
[This is Tim again, initially bounced]
And that is the issue, and what is at the root of this dispute. Tim does not
see the point of specialization or redefinition, which, in my opinion, is
why he can hold forth so strongly for XML.
Randy Neall
You are mostly correct. It isn't that I
On 06/04/2013 23:50, Thomas Beale wrote:
[This is Tim again, initially bounced]
And that is the issue, and what is at the root of this dispute. Tim does not
see the point of specialization or redefinition, which, in my opinion, is
why he can hold forth so strongly for XML.
Randy Neall
You
On 06/04/2013 23:50, Thomas Beale wrote:
[This is Tim again, initially bounced]
And that is the issue, and what is at the root of this dispute. Tim does not
see the point of specialization or redefinition, which, in my opinion, is
why he can hold forth so strongly for XML.
Randy Neall
You
On 07/04/2013 00:35, Bert Verhees wrote:
That's expedient, but it's also a guarantee of non-interoperability.
As far as I can see, also from my experience, nor OpenEHR, nor MLHIM will be
the only datamodel system on the world. Cooperation with other systems will
always need a message-format.
On 07/04/2013 12:11, Grahame Grieve wrote:
Hi Tom
You ask:
Is there a better meta-architecture available?
When actually the question at hand appears to be: is it even worth
having one?
I don't think that this is a question with a technical answer. It's a
question of what you are
On 04/07/2013 10:40 AM, Thomas Beale wrote:
Is there a better meta-architecture available?
I think is a very good architecture, that is why I am using it, but
I(we) keep having to deal with people who think otherwise.
I am not smart enough to point out why HL7v3 messaging is good or bad,
or
On 05/04/2013 13:03, Thomas Beale wrote:
[original post by Tim bounced; reposting manually for him]
On Thu, Apr 4, 2013 at 12:50 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
if you mean the competing inheritance models - I have yet to meet any XML
specialist who thinks
Hi Tim
There is no need for specialisation or redefinition in MLHIM. Concept
Constraint Definitions (CCDS) are immutable once published. In
conjunction with their included Reference Model version they endure in
order to remain as the model for that instance data. Unlike you, I
believe that the
Tim Cook wrote:
On Thu, Apr 4, 2013 at 8:40 AM, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:
You are conflating two quite different issues.
I don't think so. I demonstrated what the specifications have to say
on the matter.
Then pointed out that an internationally
On Fri, Apr 5, 2013 at 9:03 AM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
[original post by Tim bounced; reposting manually for him]
Thanks Tom. I probably posted with the incorrect email address again.
Arrrgh, organizing the simple things is difficult.
--Tim
Cook: There is no need for specialisation or redefinition in MLHIM. Concept
Constraint Definitions (CCDS) are immutable once published. In
conjunction with their included Reference Model version they endure in
order to remain as the model for that instance data. Unlike you, I
believe that the
On 04/04/2013 12:09, Tim Cook wrote:
well, since the primary openEHR projects are in Java, Ruby, C#, PHP, etc, I
don't see where the disconnect between the projects and the talent pool is.
I think if you look at the 'who is using it' pages, and also the openEHR
Github projects, you won't find
Hi Tim,
I will leave the XML vs. ADL aspects for others to discuss and address
your comments re namespacing.
I think we all agree that openEHR artefacts need proper identification
control, almost certainly something like namespacing. Some draft
suggestions have been made and are carried on
On 29/03/2013 14:15, Tim Cook wrote:
Hi Tom,
I have amended the Subject Line since the thread has diverged a bit.
[comments inline]
On Thu, Mar 28, 2013 at 9:55 AM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
one of the problems with LinkEHR (which does have many good
On 29/03/2013 16:19, Thomas Beale wrote:
Hi Tim,
I don't see any problem here. The extant open 'reference
implementation' of openEHR has been in Java for years now, and
secondarily in Ruby (openEHR.jp http://openehr.jp/) and C#
(codeplex.com http://openehr.codeplex.com/). The original
Hi!
Apache as something called The Apache Attic for unmaintained old projects
in order to keep the code/assets somewhere, see
http://attic.apache.org/Perhaps we could simply have an openEHR attic
project at github where each
unmaintained previous project gets a sub-directory-tree.
Would creating
The last of what I think are the active Subversion repositories on the
old openEHR.org server has been converted to GitHub now (the Archetype
Editor). Repositories which appear to be inactive but could be converted
if anyone wants:
* liu_knowledge_tools (Linkoping has a more recent version
21 matches
Mail list logo
