I am wondering about transforms as I move along to a complete
build/release system for a repository of archetypes.
A) Is there an XML -> ADL transform?
B) Are the HTML docs presently transformed from the ADL or XSLT'ed from
the XML?
C) Same as (B) but for the CSV files.
What I would prefer would be:
1) Only XML Archetypes & Templates.
2) At the end of the processing (e.g. changing .vNdraft to .vN inc all
references in other files) run a generate task which will generate out
the .adl files, .html and .csv.
You may want all your archetypes in XML - that is fine. The ADL is, as you have seen, more concise as a representation of the AOM. This was developed in a technology neutral environment. As XML has become more concise and the tooling is better, we have been able to provide XML as a relatively stable output.
More in line.
Adam Flinton wrote:
Dear All,
I am wondering about transforms as I move along to a complete
build/release system for a repository of archetypes.
A) Is there an XML -> ADL transform?
We have one - you can do this with the Ocean Archetype Editor - other transforms are available.
B) Are the HTML docs presently transformed from the ADL or XSLT'ed from
the XML?
At the moment it is via the .Net Kernel - as a repository tool. We want to do this with XSLT in the near future as the XML is becoming stable.
C) Same as (B) but for the CSV files.
These are from templates so they require the kernel.
What I would prefer would be:
1) Only XML Archetypes & Templates.
Why? We are always seeking to be technology neutral. XML is fine though and will probably be the more dominant form with time.
2) At the end of the processing (e.g. changing .vNdraft to .vN inc all
references in other files) run a generate task which will generate out
the .adl files, .html and .csv.
Well, it has been the other way around for some time - happy to work so it can be in all directions!
We have one - you can do this with the Ocean Archetype Editor - other
transforms are available.
Could you elaborate the "other transforms are available" part?
Would you (or anybody else on the list) happen to have an XSLT doing
XML-archetype -> ADL?
If so would you mind sharing it? It does not matter if it's in perfect
shape right now or not, it would be a good start anyway.
I agree regarding the value of being technology neutral. The "model"
has been described in UML and implemented in Eiffel (.NET) and Java
and as I understand Ruby and Python are underway too so there we have
another demonstration of "neutrality".
For a while tooling has been fairly ADL-centic when it comes to
serialising (saving) archetypes and a full suit of XML-capble openEHR
tools and utilities would be a nice addition in demonstrating
"neutrality" in the serialising domain. I believe some OWL-experiments
have also been made regarding serialisation of previous openEHR
versions. Does anybody else know of more examples?
I will be releasing the basic reference model in late April 2008. Once
that part is finished then I hope to see others pickup development on
additional functionality. Horst has asked about helping but I guess he
is busy now. I really do not want to try to engage a larger community
at this point because it is really just coding the specs as written. If
you want to help that would be cool but I don't want to try and manage a
community around it at this point.
There is a Sourceforge project page but no code there yet.
You may want all your archetypes in XML - that is fine. The ADL is, as
you have seen, more concise as a representation of the AOM. This was
developed in a technology neutral environment. As XML has become more
concise and the tooling is better, we have been able to provide XML as
a relatively stable output.
Excellant
More in line.
Adam Flinton wrote:
Dear All,
I am wondering about transforms as I move along to a complete
build/release system for a repository of archetypes.
A) Is there an XML -> ADL transform?
We have one - you can do this with the Ocean Archetype Editor - other
transforms are available.
Oh good. Is there one in the OpenEHR repository?
B) Are the HTML docs presently transformed from the ADL or XSLT'ed from
the XML?
At the moment it is via the .Net Kernel - as a repository tool. We
want to do this with XSLT in the near future as the XML is becoming
stable.
Good. I can happily help with this.
C) Same as (B) but for the CSV files.
These are from templates so they require the kernel.
Ah good so I can transform with XSLT from the .oets
What I would prefer would be:
1) Only XML Archetypes & Templates.
Why? We are always seeking to be technology neutral. XML is fine
though and will probably be the more dominant form with time.
I accept that but I am looking at things purely from a tooling POV &
having a consistent set of tools using the same technologies would be
preferable.
2) At the end of the processing (e.g. changing .vNdraft to .vN inc all
references in other files) run a generate task which will generate out
the .adl files, .html and .csv.
Well, it has been the other way around for some time - happy to work
so it can be in all directions!
It makes sense to have a complete build system i.e. "here is the
source........ -> here is the source + the transformed output
Good. I can happily help with this.
>> C) Same as (B) but for the CSV files.
>>
> These are from templates so they require the kernel.
Ah good so I can transform with XSLT from the .oets
[Heath Frankel]
The transforms cannot be done from .oets as they do not have the details of
the archetypes, only references and further constraints of archetypes. In
addition, the .oet files are currently a proprietary format used by the
Ocean Template Designer since there is no finalised specification for
templates in openEHR.
Having said that, Ocean has developed an Operational Template generator that
effectively compiles the .oet and archetypes into a single constraint
definition which can be serialised to XML and be used for these kind of
transformations. This Operational Template utilises the existing Archetype
Object Model and R1.0.1 XML schema with minor extensions based on the draft
openEHR Template specification (with minor modifications that will be
provided as implementation feedback to the specification author for
consideration). This approach has already been used by Ocean to generate
XML Schema's for a specific template using XSLT from a compiled and
serialised Operation Template. This resolves both problems identified
above.
I will also just note that the reason the template model specifications
have not been finalised in openEHR is that we thought it was necessary
to really put them to the test - in the NHS environment - and make sure
they worked. This is been fruitful - quite a few challenges came up and
we have improved the model in various ways. The model is not complex at
all, and we will get a draft up as soon as humanly possible for both the
Template specification (which is what an .oet file is) and an
'operational template', which is very nearly the same as a big archetype
(in ADL or XML, doesn't matter which). I hope people accept the
preference not to put up untested paper specifications too early! When
these new specifications are done, the current .oet files will probably
need to be migrated - an XSLT tool will be provided for this, and our
tools (which are not the only ones of course) will migrate all current
files silently to the new form. Anyone who looks at the current .oet
files should see that they are very simple files and that this migration
will be quite trivial.
Some of the other adjustments being made due to the experience of
archetypes and templates in the NHS environment are a better of version
identification, lifecycle and so on. All improvements due to this work
will be available on openEHR.org as we get the time to document them.
