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. -- 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: Fri, 11 Nov 2011 17:15:53 +0900 > Subject: Re: occurrences and cardinality in ADL, XML, JSON > From: skoba at moss.gr.jp > To: openehr-technical at openehr.org > > 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. > However, JSON/YAML are based on weakly typing languages, do not have > established scheme definition, such as XSD/ADL. > > inline. > > 2011/11/11 Thomas Beale <thomas.beale at oceaninformatics.com>: > > > ~~~~~~~~~~ first question: occurrences and cardinality ~~~~~~~~~~~~~~~~ > > but the upper limit is commonly unbounded, i.e. '*' in typical UML-like > > syntax. We could do: > > > > occurrences = < > > lower = <2> -- Integer field > > upper_bounded = <True> -- Boolean field > > I think upper_bounded is typo for upper_unbounded, but this format has the > most conformance to INTERVAL specification of assumed types library. > I agree this, because this form is easier to parse and generate an > INTERVAL instance. > I also agree with the first way of XML scheme with the same reason. > > BTW, Rubyist might be prefer this format(YAML): > > occurrence: > 2.. > > > ~~~~~~~~~~~~~ second question:existence ~~~~~~~~~~~~ > > Thus in JSON/dADL it could be: > > > > some_attr = < > > existence = <True|False> > >> > > I prefer shorter method. > To keep backward compatibility, new "exist" property > would be defined as Boolean, because it looks more narrative. > e.g. > > attribute.exist == true? > attribute.existence == 1..1 > > Shinji Kobayashi > > _______________________________________________ > 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/515767a5/attachment.html>
