Erik, Add my sigh next to yours... Lots of misunderstandings, will try to respond to most obvious ones.
I have clearly expressed that all discussions here are useful. I've made no connection to my agenda. My academic work does not even require the things I've mentioned as high priority for openEHR. I've been enjoying the discussions, and will continue to do so. Your comments about dADL below, as well as your original motivations is hinting at what I'm opposing to. Your own words: "*Having an archetype specific object-serialization language like dADL might make "archetyping" look more mysterious and suspect and might hide the fact that the semantics expressed in the AOM is the interesting thing that can be serialised in many different ways.*" This is a negative statement about ADL, right? Nothing wrong with negative statements with ADL, I have a bunch of them in my pocket. But if this is your motivation to discuss YAML, and if the thread you've started is about "replacing adl", you're talking about replacing something that has taken lots of time and effort to create. This is where we have our difference, I agree with many of the criticisms of ADL, and it is exactly at this point I try to be open minded. I can see that there are also significant advantages of ADL, and rather than suggesting that is replaced, I first hypothesize and then go ahead and prove that it can co exist with xml, json, yaml etc. My work is out there showing that adl can co exist alongside with these formalisms. From my point of view, this is quite an open minded approach, at least more open minded than replacing it, without considering what it would actually mean in other contexts. This is not the first time I'm having these types of discussions, and won't be the last. I make my point whenever I see a discussion that seems to suggest switching horses midstream. I'm sorry if I'm being a buzz killer, but I'm in favor of discussing things in a larger context, including consequences for the openEHR standard and its adoption. Reminding these consequences does not mean I'm ruling out other options. I have been discussing them in light of all the proof I have (through my work) and I've asked others to do so. I can not know about your work in advance, can I ? Let us try to eliminate the misunderstanding at this point: If this discussion concludes with the common view that yaml can be an alternative to dADL, do you think openEHR specification should replace ADL? If the answer to the previous question is yes, then do you realize that this would mean replacing all the software that uses ADL, both open source and proprietary ? If the answer to the previous question is yes, then do you have a suggestion for funding these changes? I think this is the best I can do to explain what I'm trying to include in the discussions. Best regards Seref On Wed, Dec 7, 2011 at 10:29 AM, Erik Sundvall <erik.sundvall at liu.se> wrote: > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111207/7b60fb50/attachment.html>
