Hi!
On Thu, Apr 17, 2008 at 4:11 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
Erik Sundvall wrote:
Actually I would prefer more emphasis on the view that the AM is the
main reference and that ADL is a serialization of it. But a reference
form of individual _archetypes_
Erik Sundvall wrote:
Hi!
Are all details of known possible deficiencies of the AOM listed
somewhere? Plans for bugfixes? This is vital information for all AOM
based approaches and transformations going via AOM!
agree. Probably not absolutely all just yet, but if you go to
Adam,
Indeed however there are ways of persisting a model they require at
the end of the day a recognizable document design/format.
I have already noted how using text children of an element to use a
value vs a std value attribute in the archetype xml inflates the file
sizes.
A
Adam Flinton wrote:
I have already noted how using text children of an element to use a
value vs a std value attribute in the archetype xml inflates the file
sizes.
A
Some value
/A
A value=Some value/
And Heath Frankel replied:
Your example here is contrary to your statement,
Heath Frankel wrote:
Adam,
Indeed however there are ways of persisting a model they require at
the end of the day a recognizable document design/format.
I have already noted how using text children of an element to use a
value vs a std value attribute in the archetype xml inflates the
- Original Message -
From: Colin Sutton ColinS at ctc.usyd.edu.au
To: Peter Gummer peter.gummer at oceaninformatics.com; For openEHR
technical discussions openehr-technical at openehr.org
Sent: Monday, April 21, 2008 1:02 PM
Subject: RE: Archetype documentation using XML + XSLT
Colin Sutton wrote:
With a compression algorithm, the difference may be negligible.
Heath's first example is smaller than the second when zipped due to the
repeated strings.
Of course, the result may be quite different for a larger sample where
value= is repeated.
even larger should
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080419/fdc12482/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080419/b552dc3d/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
Thomas Beale wrote:
Adam Flinton wrote:
Other limitations on using XML - it's a no-show for enterprise scale
databases
or information processing. All that wasted space starts to count when you
have
to buy two ?20,000 high availability RAID disk arrays instead of oneand
Thomas Beale wrote:
... In our own EHR
product we have had to resort to various kinds of compression, which
impact on performance, and we have to have larger disc arrays than would
be needed if the data were represented in a more efficient way. Our
engineers are currently looking at replacing
Peter Gummer wrote:
Adam Flinton wrote:
I have already noted how using text children of an element to use a value
vs a std value attribute in the archetype xml inflates the file sizes.
So you aren't convinced by Thomas's objection that putting the values in XML
attributes
Adam Flinton wrote:
Peter Gummer wrote:
Adam Flinton wrote:
I have already noted how using text children of an element to use a value
vs a std value attribute in the archetype xml inflates the file sizes.
So you aren't convinced by Thomas's objection that
Sam Heard wrote:
Dear All
After discussions with users and in consideration of the range of
platforms now being implemented, it would seem appropriate to move to
a multiplatform documentation process for openEHR artefacts. The
important specific documentation to consider are for
Peter Gummer wrote:
sam.heard signatureSam Heard wrote:
What we need is an XSL Script that consumes XML archetypes ...
Hi Sam,
XSLT is ok in small doses, but it becomes unmaintainable for anything
complex. Other approaches share the advantages claimed at
Heath Frankel wrote:
Peter,
The key is that by using XSLT we don't need to use one particular software
component and as you say, everyone can execute an XSLT script in their
chosen environment where the output should be almost the same.
We have done many XSL transformations from AOM XML and
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080417/ec579c62/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
Sam Heard wrote:
Adam
Heath Frankel has developed a proposal for a new version of the XML
(the first was a straight serialisation of the AOM) which makes it a
lot tidier. The ARB will be reviewing this at some point. It would be
good to get a few opinions sooner rather than later.
Sam Heard wrote:
Dear All
After discussions with users and in consideration of the range of
platforms now being implemented, it would seem appropriate to move to
a multiplatform documentation process for openEHR artefacts. The
important specific documentation to consider are for
Adam Flinton wrote:
XSLT requires design not different from anything else.
Use the unix app mentality i.e. that a given script does one job well
then have a number of scripts alles will be in ordnung.
this is certainly the way to go alright. It does mean you need decent
shell and/or
Adam Flinton wrote:
Oh one quick ancillary question
Does this/ Would this include Template (.oet) XHTML via XSLT?
*Adam,
The current (simple) .oet XML format for templates will soon be replaced
with a proper openEHR XSD (also simple) which is more based on the AOM,
and hence
Other limitations on using XML - it's a no-show for enterprise scale
databases
or information processing. All that wasted space starts to count when you
have
to buy two ?20,000 high availability RAID disk arrays instead of oneand
plus
the bandwidth wastage when there are
On Thu, 2008-04-17 at 16:29 +0100, Adam Flinton wrote:
umm...where to even startoh yes how about...
You left out the fact that XML cannot semantically reproduce an object
model.
Now wrt ADL.
ADL does semantically describe the AOM.
Cheers,
Tim
--
Timothy Cook, MSc
On Thu, 2008-04-17 at 18:01 +0200, Gerard Freriks wrote:
What about ASN.1 isn't that a good alternative?
This brings up a good point. ASN.1 (much like XML) is a communications
protocol.
These work well for flat message transactions where there is no need to be
concerned with temporal or
Tim Cook wrote:
On Thu, 2008-04-17 at 16:29 +0100, Adam Flinton wrote:
umm...where to even startoh yes how about...
You left out the fact that XML cannot semantically reproduce an object
model.
XML is a form of text markup. It is more analogous to the English
Gerard Freriks wrote:
The crux might be in the text in red.
Everything can be made to work.
A floating boat made out of match stick. Yes it is possible,
Gee they'll be making boats bridges out of iron steel next.
but not the bet engineering choice.
Perhaps XML is not the best choice in
Adam Flinton wrote:
Other limitations on using XML - it's a no-show for enterprise scale
databases
or information processing. All that wasted space starts to count when you
have
to buy two ?20,000 high availability RAID disk arrays instead of oneand
plus
the bandwidth wastage
sam.heard signatureSam Heard wrote:
What we need is an XSL Script that consumes XML archetypes ...
Hi Sam,
XSLT is ok in small doses, but it becomes unmaintainable for anything
complex. Other approaches share the advantages claimed at
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080416/0932eb45/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
Hi Sam,
I would also like to try out these XSLT scripts.
Besides HTML, we could also transform archetypes (XML) to other formats,
e.g. MindMap and PDF using XSLT. HTML and MindMap are good for on-line
browsing. PDF is good for print-out and off-line use. Both are needed for a
knowledge
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080416/375294da/attachment.html
31 matches
Mail list logo
