Hi Thomas, do you have some examples of the JSON produced with your P_ classes from a couple AOM instances? It would be nice to see the results.
I don't see why anyone would dislike not to have each node's type specified in the serialization form when we are talking about a schema-less format (I mean: we don't need to put each node's class in every instance of a JSON/YAML serialization from an AOM instance) and if we could agree a specification of this format (and the specification will have each nodes type, or a mapping to an AOM object that has a type defined in the AOM specs). This is not the issue, but I don't like the name "persistence" for the package, because I get the idea this is only for persisting something, but what I realy want to do is to use the serialization for "archetype interchange" (between a server and a web browser). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Sat, 12 Nov 2011 01:04:22 +0000 From: [email protected] To: openehr-technical at openehr.org Subject: Re: occurrences and cardinality 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/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; 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 _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111111/2518f9fa/attachment.html>
