After reading Pablo's post on domain types I am curious about how should they be represented on each one of the different formats. I feel they should be 'expanded' before trying to represent them in any other format, but I might be wrong. Any ideas or opinions?
2011/12/8 Koray Atalag <k.atalag at auckland.ac.nz>: > Oh, just my personal thoughts without any sanity check ? should have read > the whole thread first! My reaction was just to what was written in the > subject line of the thread and after reading Seref?s comments about the need > to focus on outstanding/high priority issues. Sorry if I have offended ? I > can?t possibly be against free discussions here ? even the most blue sky > ones which I seldom broadcast myself ;) > > > > Cheers, > > > > -koray > > > > From: openehr-technical-bounces at openehr.org > [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall > Sent: Wednesday, 7 December 2011 11:30 p.m. > > > To: For openEHR technical discussions > Subject: Re: Could YAML replace dADL as human readable AOM serialization > format? > > > > Oh sigh... > > > > Trying to be open minded, thinking a few steps ahead, sharing thoughts and > regularly reevaluating design decisions does not seem to be appreciated by > all on this list. > > > > Perhaps we need to mark some discussions or sections with... > > [Warning: may contain new thoughts] > > ...so that those of us that enjoy such discussions may continue to have them > and those that get distracted by them or can't stand them could filter out > those parts. > > > > On Tue, Dec 6, 2011 at 22:23, Koray Atalag <k.atalag at auckland.ac.nz> wrote: > > Yeah I was also wondering what is the driver/motivation/aspiration behind > using JSON, YAML etc. instead of good old ADL? > > > > Good old which ADL? Please go back in the thread and note the difference > between dADL and cADL in the reasoning, dADL is a reinvention of the wheel > (object tree serialization) cADL is an optimized DSL that I have not seen > any obvious widespread alternative to if brevity and readability is sought > for. > > > > Regarding the motivation you ask for, I would recommend going back in the > thread again to the first message... > > http://www.openehr.org/mailarchives/openehr-technical/msg06186.html > > ...under the boldface heading "Motivation:", that you may have missed, and > read the three bullet points. You may not agree but that and the rest of > this current message might reduce your wondering about the discussion > origins. > > > > I also think that we as a community should look at getting more organised > and get our efforts in tune > > > > Yes, a bit of diversity is good in order to best explore design space, but > duplicating work is a waste of time. > > If we are allowed to discuss future-directed thoughts on this list (without > people getting too upset) that may also help us tune our efforts. If we must > implement first and then discuss it will be a lot harder to avoid > duplication of work. > > > > as I know that quite interesting and though times are about to come? > > > > Are you referring to the CIMI-discusions or is it a general observation > about how the future usually is :-) > > > > Regarding CIMI I think it is valuable to try to look upon openEHR with the > eyes of newcomers. If there is unnecessary legacy in models or formats that > we don't easily see because we have gotten used to it, then now is a good > time to try reducing it while the amount of patient data using openEHR is > limited. It will be harder to change things later. Getting the template > formalism integrated with the AOM 1.5 was great in this sense, and so > is?Tom's experimentation with RM 2.0 constructs that may reduce the > ITEM_STRUCTURE hierarchy. > > > > From:?...?On Behalf Of Stef Verlinden > > +1 > > > > +/- infinity > > ?Yay, I love flame wars :-) > > > > On Tue, Dec 6, 2011 at 12:44, Seref > Arikan?<serefarikan at kurumsalteknoloji.com>?wrote: > > Given this, if you or someone else thinks that YAML can be an alternative to > dADL, there is nothing stopping anyone than implementing it and using it. > Absolutely nothing. > > > > Do you assume that if somebody is talking about a subject, then they can't > possibly be in the middle of implementing it and wanting to share thoughts > at an early stage? Please try to be a bit more open minded, I did not ask > you to be the first to implement YAML support.?You are not the the only one > implementing openEHR stuff, but I will admit that you deserve credit for, > and are great at "release early, release often" and I am not (yet). > > > > Thomas is heroically responding to all queries without judgement... > > > > I think that is an unfair description of Tom's judgment. > > > > I have a feeling that all these discussions about if this or that could > replace dADL are too hypothetical. Most of the time they are academic > discussions. There is nothing wrong with academic discussions, I am doing a > PhD here, but if the openEHR community is spending its time and resources > for academic discussions which do not necessarily connect to real life > implementations in the near term, then I think we have a problem. > > > > So if something is not on your personal implementation agenda in near time, > then it is "academic" and a waste of resources since it can not possibly be > on the implementation agenda of somebody else... :-) > > > > The reason I started looking into both JSON and YAML is that they are part > of our current implementation (partly using JSON, Javascript etc) (primarily > for RM objects) in this process I happened to see that YAML might do the job > of dADL and that we then we could reuse parser/serializer work of others > (for many programming languages) instead of maintaining dADL frameworks. I > wanted to share this thought at an early stage and I do appreciate that some > have at least responded with positive interest and curiosity. > > > > Sometimes time can be saved by discussion before implementation, especially > carefully considering what should or should not be implemented. ?People at > UCL or Ocean Informatics can probably regularly speak in person to core > openEHR decision makers and designers, the rest of as have the mailing lists > as major channels, please try to respect that too. > > > > Please do not get me wrong, all the discussion we are having here is useful, > it is just that in my humble opinion, some discussions are more useful than > others if this standard into which I am heavily investing is to go forward. > > > > You are not the only one having invested a lot of years and work in openEHR. > I would ask you and others to please allow those that want to discuss things > before and during implementation to do so if they wish to. Regarding YAML > the p.s. on the start message of this thread said: > > > > P.s.?Tom Beale and I sort of started a brief off-list discussion about YAML, > here is now an attempt to get input from more people. > > > > I think it is better for the openEHR community to have things that are of > potential interest to others, even things that are not yet tested, as > on-list discussions rather then off-list discussions, but I am not longer > sure everyone agrees and this is a bit worrying to me. I do still think > there is enough people appreciating early open discussions and will try to > continue along that path but try to remember tagging such sections > with?[Warning: may contain new thoughts] :-) > > > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 > > > > P.s.?[Warning: may contain new thoughts]?I suspect a current off-list > discussion of scalable distributed alternatives to the CKM based on GIT > might be unwelcome on the list too and it might be better to keep off-list > for a long time until it has been at least partially tested some time in the > distant future, since there are other things (like releasing other software) > that need to be prioritized first before we have time to test anything. > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
