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
> those types are defined on the laguage/standard/definition those
> structures will follow. And if we define a good serialization to
> JSON/YAML of archetypes and RM instances, we don't need a schema to
> share instances of those structures, we just need to implement the
> serialization definitions, and base the parsing on the attribute names.
>
> What do you think?
>
>
> PS: I was thinking of archetypes serialized to JSON because I want to
> build a web-based GUI Generation layer completely implemented with
> Javascript (JSON objects are javascript objects), so we can use&share
> this thin layer to show archetype-based GUI generation easily, and, if
> we have a REST layer that implement EHR-Server services, we can user
> that GUI layer to send data input to the server and get information to
> show (a complete circle). If anyone want to collaborate on the JSON
> format of ADL/AOM please send contact me.
>
> --
Again, I agree with this point of view. But XML people may not.... but
now I should clarify something...
I should have explained on other thing: what I have done in the current
AOM 1.5 implementation (but not yet documented) is to create a parallel
set of P_XX classes ('P_' means 'persistent') like P_ARCHETYPE,
P_C_OBJECT and so on. These classes formally specify the serialised form
of the archetype so there can be no ambiguity. It is these classes that
current have occurrences, cardinality and existence defined as String
properties. There are a few other simplifications as well. My proposal
is to add these P_XX class definitions to the specification. It mihgt
seem like slight overkill (and I resisted it for a long time) but once I
implemented it, it seems worthwhile, and it allows us to separate the
in-memory computable version of the AOM from a P_ version whose sole
purpose is serialisation. The Eiffel P_ classes are here
<http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/adl1.5/libraries/openehr/src/am/persistence/>;
it is easy to imagine what the Java, Python etc would look like.
So Pablo's argument, applied to the P_ classes would indeed mean that
the serialised form in JSON, YAML (also dADL) is a pure consequence of
the P_AOM classes, and no extra logic is needed. That is why I built the
P_ classes.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111112/ad63f527/attachment.html>
