Hi!
Just to make things more confused, here is another option for
occurrence serialisation in JSON, YAML etc.
Use arrays/sequences with two values for things like?occurrences, that
way it's compact (same number of characters as occurrences: 0..5)
and almost as readable, but the parser/serializer
Hm... some further thoughts on this. I originally chose the {0..1}
curly brackets mini-syntax for ADL because it is the UML 'constraint'
syntax - in UML, all diagram constraints (such as they are) are in
braces (see here
Hi Rong,
On 15/11/2011 13:44, Rong Chen wrote:
Hi all,
Since we are talking about serialization format of archetypes, I guess
we are not talking about a very large amount of data.
I would prefer to keep the serialization format(s) as close to the
object model as possible in order to
The more I think about it, the more I think we should go with the pure
String option, because:
* it is the shortest form
* it is the most human readable form
* the same approach can be used for all three of occurrences /
cardinality / existence, even though we know it is
Hi Thomas,
yes - everyone goes through the same process I think. The P_ classes I now
have in the ADL 1.5 compiler are my latest addition in this process.
[HKF: ] No, this is something you learn as it sounds like both you, I and
others do doubt have learned. The first thing a new comer
Hi all,
Since we are talking about serialization format of archetypes, I guess
we are not talking about a very large amount of data.
I would prefer to keep the serialization format(s) as close to the
object model as possible in order to reduce differences between
standards and associated tooling
: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Andrew Patterson
Sent: Saturday, 12 November 2011 12:26 AM
To: For openEHR technical discussions
Subject: Re: occurrences and cardinality in ADL, XML, JSON
On 11/11/2011 11:50 PM, Thomas
-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 11 November 2011 4:42 AM
To: Openehr-Technical
Subject: occurrences and cardinality in ADL, XML, JSON
In the current ADL 1.4-based XSDs used in openEHR, occurrences, cardinality
On 13/11/2011 22:43, Heath Frankel wrote:
I too have no problem with this custom serialisation as I have a hand-coded
serializer that does the job (I gave up on the auto-generated ones years
ago).
Heath,
just to be completely clear, since we already had quite a few posts, you
are happy to go
Hi!
On Mon, Nov 14, 2011 at 06:23, Heath Frankel
heath.frankel at oceaninformatics.com wrote:
However, others may not be so keen on this as those starting out with
openEHR like to use the built-in development tools in their favourite IDE
to generate classes that match the AM/RM and
On 14/11/2011 05:23, Heath Frankel wrote:
Hi Thomas,
The answers to the two questions below seem to be counter to each
other. I think if we want to stay true to the RM that we should do
this consistently, otherwise there is no reason why we can't deviate
in other cases such as the first
On 14/11/2011 15:41, Erik Sundvall wrote:
Hi!
On Mon, Nov 14, 2011 at 06:23, Heath Frankel
heath.frankel at oceaninformatics.com
mailto:heath.frankel at oceaninformatics.com wrote:
However, others may not be so keen on this as those starting out
with openEHR like to use the
On 11/11/2011 7:19 PM, Erik Sundvall wrote:
When a value (e.g. upper bound) may be either a number or a symbol (*
or infinity) most recieveing software will need to have logic
separating the cases anyway, no matter how they are serialized.
So then I wonder how much harder it would be to
On 11/11/2011 11:50 PM, Thomas Beale wrote:
occurrences: 1..*
well that's my opinion as well, and XML-ers always react badly! The
'proper' parser code for dealing with this form, used in the ADL parser
is (from the .y file):
Well I consider myself an XML-er and I don't see massive problems
On 12/11/2011 1:16 AM, Ian McNicoll wrote:
Apart from the size issue, readability is a particular problem because
of the verbosity of the current XML schema.
I'm not convinced that human readability should matter too much
(especially seeing ADL is meant to be the human readable format
- if we
On 11/11/2011 16:21, pablo pazos wrote:
Hi, I was thinking of this a lot: using a schema-less formats to
represent archetypes and RM instances.
I think if we agree on a common language/standard/definition, we don't
need to define the types of any node on a JSON/YAML structure, because
On 11/11/2011 5:11 AM, Thomas Beale wrote:
In the current ADL 1.4-based XSDs used in openEHR, occurrences,
cardinality and existence are expressed as XML elements. We will want
to improve this for ADL 1.5 based XML. Now, we don't want to only take
care of XML; we also need to make it work
Hi All
As ADL only states constraints there is no logical reason to include unbounded.
So no constraint expressed = RM max. This is likely to be one or unbounded.
Sent from my phone
On 11/11/2011, at 5:11 AM, Thomas Beale thomas.beale at oceaninformatics.com
wrote:
In the current ADL
Although this would work, I think that it would make ADL far less
readable and would oblige people to know always the reference model
underneath AND their parent archetype (if for some reason the parent
archetype is not available then you are completely screwed). Even if
you say that people should
On 11/11/2011 08:15, Shinji KOBAYASHI wrote:
Hi Thomas and colleagues,
I would like to discuss about the other serialization form of archetype, too.
I thought YAML could be an alternative of them.
I had forgotten about YAML I have to admit. It would be interesting to
support that in the ADL
On 11/11/2011 07:34, Diego Bosc? wrote:
Although this would work, I think that it would make ADL far less
readable and would oblige people to know always the reference model
to be clear, I am not proposing to make any change at all to ADL. ADL is
meant as a proper readable, mathematical formal
On 11/11/2011 08:19, Erik Sundvall wrote:
Hi!
On Fri, Nov 11, 2011 at 08:34, Diego Bosc?yampeku at gmail.com wrote:
Although this would work, I think that it would make ADL far less
readable
Some readability thoughts...
When a value (e.g. upper bound) may be either a number or a symbol (*
Apart from the size issue, readability is a particular problem because
of the verbosity of the current XML schema.
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
Clinical Modelling
Hi Andrew,
In principle I agree. I speak only as one of the poor sods who
sometimes has to visually check the .opt template schemas and which
use the same format. I know - get a tool :-) But even in something
like XMLSpy it can get hard to see the clinical wood for the
occurences trees.
Ian
Dr
in ADL, XML, JSON
On 11/11/2011 16:21, pablo pazos wrote:
Hi, I was thinking of this a lot: using a schema-less formats to
represent archetypes and RM instances.
I think if we agree on a common
language
25 matches
Mail list logo
