On 01/05/2013 10:28, Bert Verhees wrote:
>
> Let me explain my problems and what I wish and what I think about
> doing about that, and than what my problem is with the BMM-solution
> ---------
> I have a problem with both archetype-editors, I explained a few times
> on this list why.
> Both change archetypes while loading them, f.e. one likes to add
> node-id's to datavalues, and the other does not like that.
> There are some more incompatibilities, between the both. I forgot the
> details.
> Then one is not able to create demographic archetypes, also a problem.
> ---------
> Both are not configurable.
> I would like to have an archetype editor which can be feeded with some
> RM-definition, and configured to use it, and then is being able to
> create archetypes following that definition.
> ---------
> That does not exist, I like to build it myself, (when I have time). It
> is not very difficult, there is already code which can be used for
> understanding, from LiU, so half of the wheel is already invented.
> I think I need three months to do so. So I want to to build any RM
> depending on the feed-file.
> I would, like LinkEHR, build in in Java, in a eclipse-framework is easy.
> The archetype-editor should export to ADL, but also export to an
> XML-schema language, probably Relax NG.
all these criticisms are fair, and need to be addressed. I am hoping
that we can get some combined effort from various vendors and others to
work on a more coherent new generation of tools. The tool space is
changing a lot, and it may be that the strategy is to target Eclipse
with a group of plug-ins that together provide a good quality integrated
modelling experience. I don't believe this is that hard to achieve -
most of the difficult algorithms have been worked out in existing tools,
so a fair bit of logic can be ported or re-used. Expect some
announcements on this in the near future, and be prepared to contribute!
> ---------
> Until now LinkEHR used XML-Schema, which is good enough for expressing
> an master-RM. I am satisfied with any other way too, XMI, for example.
>
> I know there is a lot of bad XMI-software, this is because vendors try
> to put all kind of things in it, which should not be in it, and in
> this way they make it incompatible.
> But XMI itself, it is a well defined standard from OMG. It is also a
> very succesful standard. I think it must be possible to validate and
> use it in a standardized way.
actually this is not true to date; I happen to be in communication with
some of the relevant OMG people, and XMI has been recognised as a
'historically serious problem' by OMG at a recent board meeting, and is
being treated as almost an emergency situation. This was because many
tools did not respect the spec, made implementation choices where the
spec was lacking, possibly as well as adding things of their own. My
impression is that now, i.e. 2013 going forward, things should improve
reasonably rapidly. But prior to now, XMI has been a nearly unusable
format for practical purposes.
> I never studied the software-vendors well, but I think there must be
> good XMI-producing software. You mention BOUML, I know the product, it
> has a plugin-interface, at least i
> ---------
> My problem is, when you are going to use software which can only run
> from Windows and you need to create parsers to understand the output
> (like LinkEHR has published a grammar-file), it will be a stony road,
> with hard to solve bugs and incompatibility situations. We have seen
> that until now, only two archetype-editors on the market, and after
> five years, still not compatible.
You mean EA I presume? I think the next step is to see if we can
replicate the EA plug-in in other UML tools. BOUML for example runs on
all 3 major platforms, and Rational Software Architect must as well,
since it's Eclipse based. So this is just a piece of work for someone to
do. I am sure Michael will publish his plug-in for use by others.
>
> As I understand you are planning to use a niche definition, which can
> only be created by one vendor (Enterprise Architect) and let important
> software (archetype-editors) rely on that.
it's what we did so far, because at the point when we needed a solution,
there simply was nothing working that we could just use. For a future
plan... there isn't a defined plan yet, I think it is up to people here
to help define it. The two things I think are important are a) that the
/semantics/ of the BMM schemas can be supported by other solutions and
tools and b) that a schema file is human readable and writable. We might
be able to migrate to using some Ecore syntax, and/or XMI. I personally
have not had the time to go and look at this.
One thing the BMM format has achieved which we could not in any other
way has been to connect the following tools together:
* at least one UML tool (so far: EA)
* the ADL 1.5 Workbench
* the LinkEHR tool
* tools that Intermountain health are developing to produce archetypes
from Intermountain / GE Clinical Element Models
If we replace this connectivity by another method, as long as it works,
let's do it. It's just a question of determining a coherent strategy
together.
>
> Does not seem wise to me.
>
> It would be a big improvement if the BMM-files were in XML, even (but
> not directly necessary) with a schema to validate them. Then anyone
> can created them, and it is easy to build tooling, a Reference Model
> editor, next to an archetype editor.
you can generate any BMM file in XML by choosing the last item on the
context menu of any compiled schema in the ADL workbench. There is no
schema yet for that, but I'll be very happy to include one if someone
wants to write it ;-)
> ---------
> Do you know how I create archetypes (I don't if I can someone else
> having to do it :), but I work my way in LinkEHR or the Ocean editor,
> and edit them manually in a text-editor, with syntax-highlighting.
>
depends on what exactly you are doing at the moment. I generally pull
them into the ADL Workbench and edit them by hand (gvim syntax highlight
mode) from a context menu option, and recompile to debug. I am working
on visual editing, but it's not done yet.
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130501/4da3b60d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ijdecebh.png
Type: image/png
Size: 31807 bytes
Desc: not available
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130501/4da3b60d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acbejida.png
Type: image/png
Size: 106713 bytes
Desc: not available
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130501/4da3b60d/attachment-0003.png>
