David,
This
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.2ModifyCLUSTERtohavelocalvalue
is what I would realistically propose, for the CLUSTER/ELEMENT part of
the model. I will also post a
Two further variants are now up, with the second
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.4MakeITEMthefocal%27datastructure%27class
containing the more radical changes.
Comments welcome.
On 23/03/2012 12:09, Heath Frankel wrote:
I know every developer can do it better than the next but any
developer can do it better than a tool.
How true. That statement should be on the wall of every UML tool
vendor's office!
- thomas
If any developer would do better than a tool, why would anybody write tools
in the first place?
On Mon, Mar 26, 2012 at 3:26 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
On 23/03/2012 12:09, Heath Frankel wrote:
I know every developer can do it better than the next but
to replace use of generics with inheritence in future
RM versions
From: serefari...@kurumsalteknoloji.com
To: openehr-technical at lists.openehr.org
If any developer would do better than a tool, why would anybody write tools in
the first place?
On Mon, Mar 26, 2012 at 3:26 PM, Thomas Beale
Ok, thanks for the clarification.
Heath
On 23/03/2012 10:28 PM, Seref Arikan serefarikan at kurumsalteknoloji.com
wrote:
Hi Heath,
Just to clarify: my original issue is not about auto generation of classes
from XSD, whether or not one choses to do that is irrelevant if the XSD
itself is not
David Moner wrote:
I was exaclty thinking about this while seeing this proposal for the
ITEM_STRUCTURE change to a VALUE_CLUSTER:
Generally, you can do things in specifications that can't be
reproduced in actual implementations.
Since there is one specification, but many implementations, the list
of things that the specification
contains that aren't easy to implement varies widely between implementations.
The things that are
I think the topic has drifted slight from Seref's original issue, although
Java nor c# can not implement generics as well as Eiffel or as intended by
the spec author it is possible to get close enough to be usable. Similar
implementation decisions were necessary when specifying the XML schema and
Hi Heath,
Just to clarify: my original issue is not about auto generation of classes
from XSD, whether or not one choses to do that is irrelevant if the XSD
itself is not supporting generics. The problem is with the XSD (not having
support for generics) and it may or may not cascade to programming
Hi Seref,
Ruby implementation might be one of the proof for replace of generics.
I had much struggled to implement generics and got the conclusion
that we do not need it. I felt low latency between UK and Japan!
However, inheritance could be harmful, because it has too tight restriction
for
Shinji KOBAYASHI wrote:
Ruby implementation might be one of the proof for replace of generics.
I had much struggled to implement generics and got the conclusion
that we do not need it.
Ruby doesn't have generics at all, right, Shinji?
There's a comparison of generics and inheritance in an
Hi Peter,
2012/3/22 Peter Gummer peter.gummer at oceaninformatics.com:
Shinji KOBAYASHI wrote:
Ruby implementation might be one of the proof for replace of generics.
I had much struggled to implement generics and got the conclusion
that we do not need it.
Ruby doesn't have generics at all,
/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
Date: Thu, 22 Mar 2012 10:47:37 +0900
Subject: Re: Suggestion to replace use of generics with inheritence in future
RM versions
From: skoba at moss.gr.jp
To: openehr-technical at lists.openehr.org
Hi
Shinji KOBAYASHI wrote:
IteratorDvText it = someRmArrayInstance.iterator()
But I found it must be cut off by 'Occam's razor' in Ruby.
it = some_rm_array.iterator
This code looks curious for Java/Eiffel/C# user who are similar to generics,
but it is enough for encapsulated object
of generics with inheritence in
future RM versions
From: skoba at moss.gr.jp
To: openehr-technical at lists.?openehr.orgopenehr-technical at
lists.openehr.org
Hi Peter,
2012/3/22 Peter Gummer peter.gummer@?oceaninformatics.competer.gummer at
oceaninformatics.com
:
Shinji
On 22/03/2012 09:34, Seref Arikan wrote:
Hi Pablo,
I do not want to have a discussion about how to implement specs. That
was not my point. Let me try to be more direct:
Generics causes problems during implementation of openEHR if Java or
XML is involved. Java + XML has a huge user base.
2012/3/22 Thomas Beale thomas.beale at oceaninformatics.com
Instead, I think we should re-invigorate the Java Implementation
Technology Spec, that Rong wrote originally some years ago, to provide Java
implementation guidance for issues like this. All target implementation
technologies have
On 22/03/2012 13:56, David Moner wrote:
2012/3/22 Thomas Beale thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com
Instead, I think we should re-invigorate the Java Implementation
Technology Spec, that Rong wrote originally some years ago, to
I have to say, software development would be absolutely dire from my
point of view without one particular generic type: HashT, K. That
really would destroy nearly every class I have ever written!
- thomas
On 22/03/2012 01:47, Shinji KOBAYASHI wrote:
Hi Peter,
2012/3/22 Peter
On 22/03/2012 14:04, Seref Arikan wrote:
I have workarounds for the generics problems in Java, and I would be
more than hapy to contribute them to any doc. I did not know about
Rong's document.
I think I have made my point, whether or not it is a good one is a
different issue, but I don't
I should have been more specific. Generics in collections is a managable
issue :) and yes, I would not like to go back to non-generic collections
either..
On Thu, Mar 22, 2012 at 2:26 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
I have to say, software development would be
of generics with inheritence in future
RM versions
From: serefari...@kurumsalteknoloji.com
To: openehr-technical at lists.openehr.org
Hi Pablo,
I do not want to have a discussion about how to implement specs. That was not
my point. Let me try to be more direct:
Generics causes problems during
Greetings,
Looking at the UML page Tom has posted a few minutes ago made me remember
something I had in mind for some time.
With hope of avoiding any flame wars and attempts to discuss elegance of
various approaches in OO approach, may I suggest that the specs use
inheritence instead of generics
in reference to RM versions?
Since we all have very good crystal balls.
We can see a future where at RM version 2.5 there are significant
differences to RM version 1.0.2.
However; we have Mary in rural Montana USA, a patient a Dr. Jones's
office (believing strongly in future proof) and she moves
Tim Cook wrote:
There are VERY specific guidelines as to what and what does not
constitute various archetype version changes. Maybe/maybe not these
should be reviewed in reference to RM versions?
they are under review, that is for sure - we can discuss this a bit more
when the template
of THIS archetype was built against a specific
openEHR RM version.
There are VERY specific guidelines as to what and what does not
constitute various archetype version changes. Maybe/maybe not these
should be reviewed in reference to RM versions?
Since we all have very good crystal balls
will be that there will be an internal
attribute, like you propose, it will be difficult, or in some systems
even impossible, to maintain archetypes with the same name but targeted
to different RM-versions.
So I would suggest to add the RM-version attribute to the ArchetypeID.
Bert
, Sam
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Tuesday, 3 February 2009 11:53 PM
To: For openEHR technical discussions
Subject: Re: RM Versions
Tim Cook wrote:
On Tue, 2009
Sam Heard wrote:
Hi All
I would suggest that we have a very strong backwardly compatible notion on
each reference model and do not do anything that would invalidate current
archetypes in RM 1.x
This would mean that we only had to record the highest level version that an
archetype was
Exactly what I mean, we must agree, which part of the version-number
indicates a possible incompatibility concernig archetypes/RM-version.
Bert
Don't try to get too complicated. Just have a list that states that
this archetype has been validated against these RM versions. If my RM
Tim Cook wrote:
This is really an implementer's question but I'd like opinions from
everyone on it.
ADL files carry the adl version as well as the reference model name that
the archetype was built against.
With the ARB starting on release 1.1 and it looks like there may be
changes that
I meant to add: however, we should still raise a PR in openEHR Jira to
describe the problem of knowing the compatibility of archetypes with
respect to a given reference model. Tim - do you want to do this?
- thomas
Thomas Beale wrote:
Tim Cook wrote:
This is really an implementer's
*We thought about this a number of times over the last few years. The
problem is that many archetypes are completely compatible with multiple
versions of the reference model, because changes occur in other parts of
the reference model. So marking an archetype with RM version 1.0
doesn't
On Tue, 2009-02-03 at 13:29 +, Thomas Beale wrote:
I meant to add: however, we should still raise a PR in openEHR Jira to
describe the problem of knowing the compatibility of archetypes with
respect to a given reference model. Tim - do you want to do this?
Yes. I'll do this in the
Tim Cook wrote:
On Tue, 2009-02-03 at 13:29 +, Thomas Beale wrote:
I meant to add: however, we should still raise a PR in openEHR Jira to
describe the problem of knowing the compatibility of archetypes with
respect to a given reference model. Tim - do you want to do this?
Bert Verhees wrote:
*We thought about this a number of times over the last few years. The
problem is that many archetypes are completely compatible with multiple
versions of the reference model, because changes occur in other parts of
the reference model. So marking an archetype with RM
Hi Thomas,
Whilst I agree that in most circumstances it would be of no interest
to authors, there may be circumstances where it is important to know
the exact RM version and revision, perhaps for safety-critical
archetypes, which the 'consumers' wish to check meticulously. I see no
harm in
Ian McNicoll wrote:
Hi Thomas,
Whilst I agree that in most circumstances it would be of no interest
to authors, there may be circumstances where it is important to know
the exact RM version and revision, perhaps for safety-critical
archetypes, which the 'consumers' wish to check
Hi Thomas, I was suggesting the RM version be recorded when the archetype is
officially published or revisioned and re-published. This is the only time
when an archetype author can be expected to take some account of the
underlying RM when designing or revising the model. It is not a perfect
Thomas Beale schreef:
Bert Verhees wrote:
*We thought about this a number of times over the last few years. The
problem is that many archetypes are completely compatible with multiple
versions of the reference model, because changes occur in other parts of
the reference model. So
versions. If my RM
version is in the list I okay. There aren't going to be too many RM
versions anyway.
--Tim
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message
Ian McNicoll wrote:
Hi Thomas, I was suggesting the RM version be recorded when the
archetype is officially published or revisioned and re-published. This
is the only time when an archetype author can be expected to take some
account of the underlying RM when designing or revising the
This is really an implementer's question but I'd like opinions from
everyone on it.
ADL files carry the adl version as well as the reference model name that
the archetype was built against.
With the ARB starting on release 1.1 and it looks like there may be
changes that impact software. I
44 matches
Mail list logo
