XML Focus Group for openehr

Clinical (archive)
1

Dear All,

After the series of posts on "Re: Archetyping Methodology-Mind Mapping" back in July and (see below) on Mind Mapping Archetypes. I raised a question to a group within Ocean Informatics which later included others listed below:

Sebastian Garde; Lisa Thurston; Thomas Beale; Heather Leslie; Adam Flinton; Heath Frankel;Federici Massimilliano; Olusegun Odujebe; Sam Heard

The proposal is to have an XML Focus Group and/or List within openehr to look and work at opportunities in this area. Open for discussion and probably adoption?!

I believe the XML Archetypes and Reference Model Schemas hold a lot of promise as an implementation platform interface for openehr.

The more i have looked at it, the more I see possibilities that can be implemented across diferrent implementation groups.

They present the opportunity of XML as a powerful interface and transformation platform.

The opportunity is that the current Schemas need modification to represent the ADL absolutely.

Some of us are committed to exploring the opportunity that Mindmapping presents as a simple editing platform for archetypes and templates (especially for clinician groups ) and the generation of ARCHETYPES FROM THE MINDMAPS. In addition we are looking at the trip back from archetypes to Mindmaps.

There was a suggestion that the limited posting between the individuals above be brought to this mailing list.

Thanks

'Segun

Olusegun Odujebe, MD, CISA, PMP

2

Dear all,

Interesting.
But …

XML is not the focus we need.
We need to focus on the clinical information models,
and how to use the expressions of these in EHR-systems.
Whether we use XML or ASN-1 is irrelevant.

So, although I see some advantages of using XML, I see no harm in looking at ASN-1 for ways to express Archetypes.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

3

Hi Gerard,

I think the significance of the XML format in this context is simply that it is easier to build on new tools such as mindmap front ends without having to understand ADL or the various parsers.

I am certainly very interested in any efforts to develop a simple mindmap conversion to an archetype formalism

Cheers,

Ian

Ian

4

Ian Mcnicoll schreef:

Hi Gerard,

I think the significance of the XML format in this context is simply
that it is easier to build on new tools such as mindmap front ends
without having to understand ADL or the various parsers.

This is interesting, creating archetypes with mindmap. In my opinion, it
is very difficult to create good archetypes without having knowledge of
the reference model.
So a creating valid archetype with a mindmap-tool seems to me
impossible. Or are you talking about mindmap-tools which are aware of
the reference model? Are the not capapble of writing ADL?
I am very interested in the tools you talk about.

In case the mindmap tool is not aware of the reference model, the
produced XML does not seem very useful to me. Thus you need a conversion
of rough mindmap-schemes to valid archetypes.

But also in case of mindmap tools which create valid archetypes, it must
be simple to convert from XML to ADL.

As Gerard, I cannot see any added value in archetypes created in XML

Maybe you can explain more detailed what software and tooling you are
talking about.

Thanks
Bert

5

Hi Bert,

This is interesting, creating archetypes with mindmap. In my opinion, it
is very difficult to create good archetypes without having knowledge of
the reference model.

I agree but most clinicians asked to contribute to archetype and
template development will not be 'creating archetypes'. The major
strength of the openEHR layered approach is that 'normal' clinicians
do not need to have any real understanding of the Reference layer.

My feeling is that the real challenge in creating good-quality
archetypes is in getting the general structure correct, in particular,
accounting for the differing layers of granularity that might be
required by different clinical groups. i.e the challenge is in
designing the shape of the archetype, to allow for expansion as new,
more detailed requirements emerge alongside simpler representations.
Deciding the data types at the leaf nodes is comparatively easy.

Mindmaps are a great way of brainstorming a constrained clinical
concept when working with a group of clinicians who have minimal
openEHR training and possible even less interest! They allow people to
be expansive about requirements and allow the modeller to quickly
refactor the shape of the initial model into a series of achetypes. It
is then fairly easy to express this as a formal archetype via one of
the editors but it would save a great deal of typing and clicking if
we could import the 'untyped' Mindmap into the editor as a set of
Text and Cluster nodes ,then refactor these nodes to more appropriate
Entry types.

Cheers,

Ian

So a creating valid archetype with a mindmap-tool seems to me
impossible. Or are you talking about mindmap-tools which are aware of
the reference model? Are the not capapble of writing ADL?
I am very interested in the tools you talk about.

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com

Consultant - IRIS GP Accounts ian@gpacc.co.uk

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

6

Ian, you are right, it is a good thing if clinicians can contribute in creating archetypes, this should be one of the goals.

But at this moment, this is not posible, for the clinicians I know.

A mindmap tool would be a good addition to the openehr-tooling. Maybe I create it later on, next year or so. It may be not too hard, there is already a lot of example-code for the needed parts.

The point of this discussion is, however, also look at the subject of the thread, does XML have added value above ADL for archetypes.

In both XML and ADL is it possible to express the reference model.

It seems to me very easy to switch from ADL to XML and back. The code for this is maybe ready, or can be build in short period, f.e. based on the ADL-parser and ADL-Serializer from Rong

Maybe there is something which cannot be cexpressed in one of another, but I am not aware of that.

So what would be the added value then, in this matter, of XML?

Bert

7

Don’t get me wrong.

XML is only one pice of he puzzle.
Important? Yes!
It is an important transport mechanism.
But what problems do we have to solve in the XML-space?

It is an important transport mechanism for which there are many tools.
But it is not the only one or the best one.

The MindMap conversion is intriguing.
Do not forget producing a MindMap is like the mathematical operation of the Derivation performed on a function.
One looses important information.
Integration of the Derivative does bring back the original function.

In other words a lot of knowledge has to be added to the MindMap and hidden from the user in order to make that happen.
Normal MindMap tools will not be able to handle that, because they were not designed to to that.
A project like this entails to the design and production of a new Archetype Tool.

We must question the value of doing that when I know that making archetypes will be done by a handful of people in each country.
Healthcare providers will be more exposed to Templates, in these they express their local requirements.
Academically it will be a very nice project.
But what is the real practical value?

I’m not against Tooling projects.
I see more need for the production of a good collection of Archetypes using the tools we have
and produce Archetype and Template rules and validate them.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

8

Hi Bert,

The argument for XML in the current context is purely that it can
allow developers with minimal knowledge of openEHR to add value to the
modelling process via extra tools, such as mindmapping, forms
generators and more generic 'requirements gathering' environments. The
NHS are using the XML variants to do cross-checks on archetype,
specialisation and template integrity within their models repository.

Of course all of this can, and in time will be done, within the
ADL-based tools but having the XML variant lowers the entry barrier
for those who have XML/XSLT skills. The current Ocean archetype editor
can create/maintain ADL and XML representations in parallel, which is
the NHS default.

This is purely of value in the openEHR modelling space, the value of
XML archetypes in the run time enviornment is less compelling.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com
Consultant - IRIS GP Accounts ian@gpacc.co.uk
Member of BCS Primary Health Care Specialist Group – www.phcsg.org

9

Ian McNicoll schreef:

Hi Bert,

The argument for XML in the current context is purely that it can
allow developers with minimal knowledge of openEHR to add value to the
modelling process via extra tools, such as mindmapping, forms
generators and more generic 'requirements gathering' environments. The
NHS are using the XML variants to do cross-checks on archetype,
specialisation and template integrity within their models repository.
  

In that case, for developers to do useful things in this context, they
can translate ADL to XML, if they need that.
That is up to them, as you say, OpenEhr-tooling is already facilitating
this. It only takes a small step for those developers.
It is even possible to create a library which does that, compare it to
base64 encoding, which has small libraries for almost every programming
environment.

For me, there is an advantage for ADL above XML, and that is ADL is
easier to read for humans. I found this argument somewhere in the specs,
it says:
"Although ADL is primarily intended to be read and written by tools, it
is quite readable
by humans and ADL archetypes can be hand-edited using a normal text editor"

This is much more difficult for XML. Maybe when the
OpenEhr-standardization-comity decides that this argument is no longer
valid, and should be removed from the specification. I would regret that.

I don't know if there are more basic reasons to define a primarily
archetype definition language, maybe something as a definition
constraint, something like: "if you can't express it in ADL, then it
can't be a valid archetype". (you cannot turn around this rule).
See it as a law, if you can't express it in Dutch, English, whatever
language, then it can't be a valid law in the Netherlands, UK, etc.
(I don't know if this makes sense. :wink:

Of course all of this can, and in time will be done, within the
ADL-based tools but having the XML variant lowers the entry barrier
for those who have XML/XSLT skills. The current Ocean archetype editor
can create/maintain ADL and XML representations in parallel, which is
the NHS default.
  

The current (published) Archetype-editor from Ocean, is, as far as I
know, not capable of creating archetypes in the demographic part of the
reference model. I don't know how the NHS works with this. According the
OpenEhr standard, you cannot create an EHR without demographic-archetypes.

This is purely of value in the openEHR modelling space, the value of
XML archetypes in the run time enviornment is less compelling.
  

I agree.

Bert

10

Don’t get me wrong.

XML is only one piece of he puzzle.
Important? Yes!
It is an important transport mechanism.
But what problems do we have to solve in the XML-space?

It is an important transport mechanism for which there are many tools.
But it is not the only one or the best one.

The MindMap conversion is intriguing.
Do not forget producing a MindMap is like the mathematical operation of the Derivation performed on a function.
One looses important information.
Integration of the Derivative does bring back the original function.

In other words a lot of knowledge has to be added to the MindMap and hidden from the user in order to make that happen.
Normal MindMap tools will not be able to handle that, because they were not designed to to that.
A project like this entails to the design and production of a new Archetype Tool.

We must question the value of doing that when I know that making archetypes will be done by a handful of people in each country.
Healthcare providers will be more exposed to Templates, in these they express their local requirements.
Academically it will be a very nice project.
But what is the real practical value?

I’m not against Tooling projects.
I see more need for the production of a good collection of Archetypes using the tools we have
and produce Archetype and Template rules and validate them.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

11

gerard wrote:

We need to focus on the clinical information models,
and how to use the expressions of these in EHR-systems.

Whether we use XML or ASN-1 is irrelevant.

If you are talking about wider adoption the choice does seem quite relevant to me, because it addreses the “missing link” to real life. It is OK to stay safely away from the transport layer for some time and polish semantic modelling methods. Eventually we will have to move into real data, put that into the models, and actually get it across some cable. You need eg. XML or ASN.1 to do that. This will be the time when implementers will rise from their desks and join us.

Most EHR implementers will be ready to use XML. If we go into the medical device arena, implementers will be happier with ASN.1 because embedded processors have limited processing power and storage place. In order to attract both of them we will have to demonstrate a working toolpath from end to end, with modelling of single archetypes, assembly into documents and messages and EHRs, repositories, codes and ontologies management, etc. It will be necessary to have that in both XML and ASN.1 and to demonstrate how archetypes can connect all this.

EHR and medical device implementers are two seperated communities at the moment. They do not have a clear standardised way to exchange semantics right now (not even within both communities). This will come soon with the full flood of Continua, Microsoft, Google, etc. If we can use archetypes and show how they support and connect both worlds, that would be a real treat.

We are at the moment starting a funded research project that will dig into this, and hopefully bridge from medical devices into the EHR arena. We are very fond of the idea to use archetypes as a vehicle and will try to demonstrate this in practice. Cooperation and interest is very welcome. This will last 4 years from now, so there is a chance to actually see things move. Should anybody be interested please contact me.

We are also willing to actively contribute to standardisation activities into that direction, provided they connect the necessary groups within openEHR, CEN, ISO, HL7, Continua and IHE etc.

Greetings from Vienna,

Stefan Sauermann

12

Dear All,

I have found the responses to to the topical issue(s) quite intriguing...there really several issues that have arisen from the threads.

I believe Stefan and Ian have quite wonderfully summed up the raison d'etre of such an implementation, so I won't go that way.

However I believe we need to leverage on the 'OPEN' in openehr!Really look at what works for the ultimate Users of the platform widely.

1.If openehr RM is a platform then there would need to be differing layers of abstraction based on use.

2. As a Model, we can have a model of the model...etc.

3. if we are going to speed up adoption and real implementation then we can't ignore the fact that the XML group of technologies and their cousins hold a great promise and actually drive a significant proportion of live interoperability and integration projects.

Which takes me to the point: The real opportunity is to build a pragmatic XML model on top of the current ADL-based one...I think. Openehr is already working on that through the XSDs, we only need a greater focus.

Another thing, like ADL, XML was and is meant to be both human and machine readable. So there is really no difference. The suggesstion is not to do away with the ADL but to really extend the opportunities the ADL and openehr RM provides through a technology platform like XML that has proved its worth.

The Mindmap issue may appear difficult but not impossible. I thought that the real opportunity for archetypes and templates is for Clinical Domain Experts to be able to represent data and information as derived from their KNOWLEDGE. Hence the easier they are able to do this the more widespread the adoption of the openehr RM as an EHR Model and probably interoperability framework.

For some of us in the developing world, a more pragmatic approach will definitely help. Except if the point is academic...But it is not.

Olusegun

Olusegun S. Odujebe,MD,CISA,PMP
Enthusia Consulting
Lagos Nigeria

13

I skimmed some of the previous posts on this... I may be missing
something here, but all archetypes are already available in XML, and
there is already an XSD for archetypes, published in the specifications
location.

what else is required?

- thomas beale

Segun Odujebe wrote:

14

Hello, especially to Tom and Segun,
Segun, thanks for your interest, if you are willing to join work on
connecting medical devices to health record systems using available
standards, then please contact me. We are looking for companies and groups
of users, and want to implement real clinical usecases over the next four
years. Everybody else who is interested in that, too.

Tom, if you say that archetypes are available in XML, then I guess you refer
to the archetype itself. It is good to know that this is available in XML as
well, and not only in ADL.

What about instances? I know that transportation of instances in real life
has been demonstrated, but not by many, and the world still needs to be
tought that this really happens. The world being implementers in a wide
range of companies that are designing products, EHRs, medical devices, lab
machines, etc.

These implementers are very much focusing on transport formats. We veteran
standards heroes know that the transport formats of instances need to be
automatically derived from archetypes, and both XML and ASN.1 (and many
others) need to be available, and are available if you whom to ask exactly
how. I did ask Bernd Blobel, and he told me that I had to do a doctoral
thesis at his lab to exactly learn how. I myself am willing to go that far
in our research project (Bernd, sorry but I may eventually have to skip the
thesis part, but this will definitely be a heavy learning experience).

The average implementer will not have the time. They still are firmly
convinced that a transport format worth its salt is handcrafted, and a
"reference model" is something for enlightened souls and philosophers. This
is the gap that I think needs to be addressed now. Tens of thousands of
implementers all over the planet have to learn the "new archetyped way" to
generate transport formats.

It is not enough to just say "It is possible, it has been done." We have
been on the moon, but we now need to get mass tourism going there.
Archetypes are at the moment not something for the average traveller.
Implementers need very well defined, simple, proven development toolpaths
that plug and play.

What we therefore want to do in this reasearch project is the following:

- to take IEEE 11073.20601 (+ device specialisations) information models
(e.g pulsoximetry samples, weight scale, blood pressure, ... They have a
number of them ready with nomenclature and all, more to come)
- make archetypes out of them
- do the same for other domains like the laboratory report. (this is a
slightly different line, but fits nicely)
- find or create tools that can handle these models and archetypes in
numerous ways:
  - assemble messages and documents in correct ways, compliant to the
reference model
  - generate code that can fill these models with content and generate
instances
  - generate code that can convert these instances to XML (with CDA a
high priority)
  - generate code that can convert these instances to ASN.1 (according
to the 11073, or other appropriate coding rules)
  - generate code that can take an ASN.1 coded instance and fully
automatically convert it e.g. to an XML (CDA) coded one, so that it can be
fed into a EHR system with full semantics. Also do other conversion and
reassembly tasks.

- do this in close cooperation with companies (tools developers, device
developers, clinical IT vendors, etc) and clinical users, so that the
resulting tools landscape really is forced through the complete range of
requirements, both technical and also management e.g. "delivery on time",
ease of use, low cost, etc.
- target selected clinical applications and cooperate specifically with
whoever it takes from the start
- keep close contact to all necessary standardisation groups and projects,
so that "not invented here" and "reinvent the wheel" can be avoided wherever
possible
- demonstrate that it works
- demonstrate that it scales, both in numbers, richness of semantics,
complexity, and range of usecases and settings.
- demonstrate the many other beautiful things that you can do with a nice
and fat pack of sematically structured data: searches, decision support,
etc.

My experience is that no single tool exists at the moment to cover all of
these things. We will therefore have to identify a big bunch of existing
knowledge and tools, and plug them together in a useful way. We (and all the
implementers on this planet) will need a lot of help here, from many groups
of people who have been working on these tools for years. openEHR is
definitely one of these groups, IEEE, CEN, ISO, HL7 are others.

So, anybody who is willing to join in this, or already is on the way, is
very welcome. Should somebody be there already, we are happy to learn from
them, and tell everybody else. We will also do search activities to find
you. Its tooltime.

Sorry for being so long, I hope that this does not blast the bytes limit,
greetings from Vienna, and hope to see you soon, maybe in Istanbul,
Stefan Sauermann

15

Stefan Sauermann wrote:

Hello, especially to Tom and Segun,
Segun, thanks for your interest, if you are willing to join work on
connecting medical devices to health record systems using available
standards, then please contact me. We are looking for companies and groups
of users, and want to implement real clinical usecases over the next four
years. Everybody else who is interested in that, too.

Tom, if you say that archetypes are available in XML, then I guess you refer
to the archetype itself. It is good to know that this is available in XML as
well, and not only in ADL.
  
Archetypes have been available in XML for nearly 2 years I think by now.

What about instances? I know that transportation of instances in real life
has been demonstrated, but not by many, and the world still needs to be
tought that this really happens. The world being implementers in a wide
range of companies that are designing products, EHRs, medical devices, lab
machines, etc.
  
If you want to see some example XML, just go to
http://demo.oceanehr.com/EhrView14/ and login as guest/guest; then
choose a patient surname (US census data, so slightly anglo-centric
names); when you are on a patient, you can see in the lower right hand
corner a link to show the XML for the content. This is direct
template+archetype based content, straight from the EHR server. It is
what is wrapped up inside an EHR Extract.

These implementers are very much focusing on transport formats. We veteran
standards heroes know that the transport formats of instances need to be
automatically derived from archetypes, and both XML and ASN.1 (and many
others) need to be available, and are available if you whom to ask exactly
how. I did ask Bernd Blobel, and he told me that I had to do a doctoral
thesis at his lab to exactly learn how. I myself am willing to go that far
in our research project (Bernd, sorry but I may eventually have to skip the
thesis part, but this will definitely be a heavy learning experience).
  
no need for a PhD to learn that; it is all implemented today. Well, I
don't know about ASN.1 - not sure if anyone needs archetypes in that
form, but if so, I presume the transform could be created.

The average implementer will not have the time. They still are firmly
convinced that a transport format worth its salt is handcrafted, and a
"reference model" is something for enlightened souls and philosophers. This
is the gap that I think needs to be addressed now. Tens of thousands of
implementers all over the planet have to learn the "new archetyped way" to
generate transport formats.
  
well, these people will of course have a long future ahead of them
spending vast amounts of time doing what can be done far better by a)
clinicians, who know he data, and b) software schema generators, that
can automatically generate message formats as just one kind of generated
output. Manually generated messages may be better for the personal
economics of such people, but it is not better for the economics of
healthcare providers, governments or any other larger scope.

The openEHR aproach to those kinds of messages is the Template Data
Schema, which is implemented already, and documentation will be provided
on openEHR.org as soon as humanly possible.

It is not enough to just say "It is possible, it has been done." We have
been on the moon, but we now need to get mass tourism going there.
Archetypes are at the moment not something for the average traveller.
Implementers need very well defined, simple, proven development toolpaths
that plug and play.
  
this is why the TDS exists - it removes the need for message users to
have to know anyhting at all about archetypes, templates, the reference
model or anything else esoteric. They can just work with an XSD for a
given message, and get on with what they know best - e.g. their
specialist application.

What we therefore want to do in this reasearch project is the following:

- to take IEEE 11073.20601 (+ device specialisations) information models
(e.g pulsoximetry samples, weight scale, blood pressure, ... They have a
number of them ready with nomenclature and all, more to come)
- make archetypes out of them
  
well, actually, you should be able to review the existing ones - BP,
weight, pulse oximetry are all there.

- do the same for other domains like the laboratory report. (this is a
slightly different line, but fits nicely)
- find or create tools that can handle these models and archetypes in
numerous ways:
  - assemble messages and documents in correct ways, compliant to the
reference model
  - generate code that can fill these models with content and generate
instances
  - generate code that can convert these instances to XML (with CDA a
high priority)
  - generate code that can convert these instances to ASN.1 (according
to the 11073, or other appropriate coding rules)
  - generate code that can take an ASN.1 coded instance and fully
automatically convert it e.g. to an XML (CDA) coded one, so that it can be
fed into a EHR system with full semantics. Also do other conversion and
reassembly tasks.
  
all of this is doable. All that is needed is the funding;-)

- do this in close cooperation with companies (tools developers, device
developers, clinical IT vendors, etc) and clinical users, so that the
resulting tools landscape really is forced through the complete range of
requirements, both technical and also management e.g. "delivery on time",
ease of use, low cost, etc.
- target selected clinical applications and cooperate specifically with
whoever it takes from the start
- keep close contact to all necessary standardisation groups and projects,
so that "not invented here" and "reinvent the wheel" can be avoided wherever
possible
- demonstrate that it works
- demonstrate that it scales, both in numbers, richness of semantics,
complexity, and range of usecases and settings.
- demonstrate the many other beautiful things that you can do with a nice
and fat pack of sematically structured data: searches, decision support,
etc.

My experience is that no single tool exists at the moment to cover all of
these things. We will therefore have to identify a big bunch of existing
knowledge and tools, and plug them together in a useful way. We (and all the
implementers on this planet) will need a lot of help here, from many groups
of people who have been working on these tools for years. openEHR is
definitely one of these groups, IEEE, CEN, ISO, HL7 are others.
  
well for the conversions to and from standard openEHR into a format like
CDA - remember you have to talk about a specific CDA schema - a
framework is required. We have develped one in Ocean that uses small
fragments to convert pieces of each custom message/CDA etc in and out of
openEHR format. We think this is a prime candidate for open sourcing -
none of that work should be done twice. (But it would be smarter to just
forget CDA and work with EN13606, since it is a lot more generic, and
the transformation is simpler and therefore safer).

So, anybody who is willing to join in this, or already is on the way, is
very welcome. Should somebody be there already, we are happy to learn from
them, and tell everybody else. We will also do search activities to find
you. Its tooltime.

Sorry for being so long, I hope that this does not blast the bytes limit,
greetings from Vienna, and hope to see you soon, maybe in Istanbul,
Stefan Sauermann

As I say above, all that is needed is funding; nearly everything you
mention above has already been done; things like ASN.1 conversion would
be extra.

- thomas beale

16

Hi Stefan,

> These implementers are very much focusing on transport formats. We

veteran

> standards heroes know that the transport formats of instances need to be
> automatically derived from archetypes, and both XML and ASN.1 (and many
> others) need to be available, and are available if you whom to ask

exactly

> how. I did ask Bernd Blobel, and he told me that I had to do a doctoral
> thesis at his lab to exactly learn how. I myself am willing to go that

far

> in our research project (Bernd, sorry but I may eventually have to skip

the

> thesis part, but this will definitely be a heavy learning experience).
>

no need for a PhD to learn that; it is all implemented today. Well, I
don't know about ASN.1 - not sure if anyone needs archetypes in that
form, but if so, I presume the transform could be created.

I can go through this with you.

Regarding ASN.1, I will not pretend to know anything about it but what we
have done is used the Fast Infoset XML Binary encoding, which is based on
ASN.1 I believe, to compress the data instances. We use a third-party
MS.NET component but there are also open source Java components available.

Regards

Heath

Heath Frankel
Product Development Manager
Ocean Informatics

email: heath.frankel@oceaninformatics.com