Hi Koray, Autocomplete for a syntax colored ADL editor is one of the features planned for Opereffa Eclipse plugins, FYI.
All the best Seref On Mon, Sep 28, 2009 at 5:37 AM, Koray Atalag <koray at cs.auckland.ac.nz>wrote: > Hi Roger, > > I'd really like the kind of functionality you describe and it is definitely > desirable...I was little concerned about the workload implications to > already supersaturated core members. And I must say worried about the > wording in subject of the thread - the content and quality of openEHR > documents look pretty satisfactory to me at the moment. Sorry if my message > has been little "reactive" - but I can not help but become emotional when it > comes to openEHR ;) > > BTW I'd be very interested to know if anyone prefers to use a "text editor" > when creating/updating archetypes? It'd be very cool to have an "ADL" aware > editor and have kind of "intellisense" functionality for writing ADL > expressions for advanced users. > > Cheers, > > -koray > > > Roger Erens wrote: > > Hi Koray, > > If you imagine some sort of workbench or platform that can be used to > create openEHR-based applications, wouldn't it be nice if the workbench > would offer the creator/developer some sort of help along the way? Not with > tooltips saying something like "See the reference documentation" but more > like tooltips containing snippets of the reference documentation, e.g. > "Insert here an object of type DV_TEXT: <snippet of Data Types IM > inserted>". If you envisage this workbench or platform in a web-centric > setting, it's not too hard to see that a translation service (Yahoo's or > Google's) could machine-translate those snippets. Of course it should be > very clear that the originally published (English) specification on > openEHR.org is authorative. > > I think the OP was pointing into this direction, and not a multi-million > resource-intensive translation process. > > From-the-pitfalls-yours, > > Roger > > On Sat, Sep 26, 2009 at 03:23, Koray Atalag <koray at cs.auckland.ac.nz>wrote: > >> Hi All, >> >> I really appreciate the "mental" exercise to achieve a better >> documentation; however I must say I am really surprised to watch the recent >> discussions like this one because I wonder if we, as a community yet to >> solve many fundamental problems and overcome the many challenges, have >> enough resources to deal with this at the moment. Frankly I disagree with >> the need to translate all the specs and documentation into other languages >> at the moment - not to say that this is trivial but I don't think we are at >> that stage at the moment. And when we become (if ever!) a multi-million $$$ >> foundation then I suggest looking at how ISO or national bodies approach the >> multi-lingual documentation problem. >> >> While I believe in and most importantly own a couple open source projects >> myself, I see many from FOSS rounds getting into the pitfall of seeing >> software as either evil or good or having the illusion of open source as a >> merit by itself. That is not true...I hope we don't end up trying to FOSS >> everything "just for the sake of" the "open" in our prefix ;) >> >> And ?eref I don't think much people left in Turkey to bother with openEHR >> anyways! >> >> Cheers, >> >> -koray >> >> Seref Arikan wrote: >> >> Tom, >> I'd be happy to help you out, just let me know what you need me to do. >> I'll be putting all of the documentation into Eclipse plugins of Opereffa >> anyway. We can turn that task into an experiment to lay out some sort of >> method for transformation of documentation to other formats. >> >> Cheers >> >> >> On Fri, Sep 25, 2009 at 6:08 PM, Thomas Beale < >> thomas.beale at oceaninformatics.com> wrote: >> >>> >>> Unfortunately I can't make any conversion mission a top priority, but >>> let's commit at least to an experiment which I can initiate - I will >>> generate the 'standard as-is' XML output from one specification (say the >>> data types) and make that available - Seref or someone else may be able to >>> determine what rules it is following; in the meantime I can do a bit of >>> research on what needs to be done to a FM document to make its XML output >>> DITA based. >>> >>> - thomas >>> >>> >>> Tim Cook wrote: >>> >>> Hi Seref, >>> >>> Thanks for your concerns and well thought out points. >>> >>> If you read my original posting, I didn't ask Tom to stop using >>> Framemaker. I ask for some output in place of (or in addition to) the >>> PDF and Framemaker formats. I'll happily accept .doc files at this >>> point. >>> >>> It seems that we have a different perspective on what the sense of trust >>> in the community is also. But that is an entirely other subject. :-) >>> >>> --Tim >>> >>> >>> On Fri, 2009-09-25 at 11:08 +0100, Seref Arikan wrote: >>> >>> >>> Dear all, >>> I'd like to express my concerns about practical outcomes of suggested >>> changes, changes based on potential benefits. I'd appreciate your >>> input about the use cases we are discussing just to make sure that I >>> get this right. >>> First of all, translation of openEHR documentation to other languages >>> is a very critical task, which would be quite a challenge, because we >>> are talking about very high quality documentation, to which I keep >>> going back quite often, mostly to find out that a point that I was >>> missing has already been there, expressed carefully. At one point I've >>> thought about translating the docs to Turkish, my mother tongue, and >>> realized that not having a Framemaker licence was the least of my >>> problems. Reflecting the same quality, and more important than that, >>> the same semantics consistenty in other languages is a huge challange. >>> It requires understanding of the domain, the standard, and possesion >>> of more than ordinary control over two languages, one being English. >>> Also, as a member of openEHR community I would not like to see >>> translations of the specs in the wild, with no official approval or >>> inclusion from openEHR foundation, since this can easily lead to >>> confusing documentation on an already confusing topic, which is >>> challanging enough to master with really good docs. >>> I would like to know if there are efforts, or even intentions of >>> translating this documentation to other languages, and the owners of >>> these intentions. How many translations of the documentation will be >>> for Spanish for example? If a person would give this task a try, due >>> to reasons expressed above, he/she would have to possess quite a lot >>> of time, skills and he/she would have to communicate with openEHR to >>> make sure that the outcomes do not do harm instead of doing good. My >>> opinion is, this would be an effort linked to an institutuion like a >>> university, or a government agency, working with openEHR. I can't see >>> people working in their homes/offices on their own, doing this whole >>> work, and if there are people like this, I really want to know them. >>> The point? Well, the translation would mostly likely be performed by >>> people with resources. A framemaker 9 licence would be the least of >>> their problems. Again, please let us know if there is a person out >>> there, comminting to translation, committing to ensure its quality, >>> and committing to its maintanance, and is not able to move forward, >>> just because he/she can't afford a licence for Framemaker. >>> I appreciate the effort for preserving the idea of openness in all >>> aspects of openEHR, but I want to see Tom producing documentation >>> efficiently. This is his time spend in front of a computer, and I do >>> not want him working slower, or producing inferior quality output, >>> which is what will obviously happen if he does not use Framemaker. I >>> have to confess that I am failing to see the fairness of asking Tom to >>> commit more of his time today, for potential future benefits, which >>> have significant prerequisites that must be covered, before they can >>> be realized. >>> Having used Framemaker html, xml outputs to produce documentation for >>> Eclipse plugins, I'm fine with the idea of documentation being >>> exported to these formats from framemaker. PDF outputs are simply read >>> only docs, doing exactly what they are created for, providing cross >>> platform access to documentation. So I don't see the point of >>> critisizing them for not being appropriate for translation either, >>> since they are not produced to be edited at all. >>> Conclusion: please let us see concrete use cases,that justifies making >>> the suggested changes, build on not only on idealism but also actual >>> cost benefit analysis, and we can build a solution, or a roadmap from >>> there. I'd rather see this wonderful community move forward, trying to >>> stay close to its principles as much as it can, with its available >>> resources, than see it watch others progress while we fail to do so >>> just because we're getting ready for a better future all the time. >>> >>> Best Regards >>> Seref >>> >>> >>> On Fri, Sep 25, 2009 at 9:18 AM, Tim Cook<timothywayne.cook at gmail.com> >>> <timothywayne.cook at gmail.com> wrote: >>> On Fri, 2009-09-25 at 10:08 +0200, Erik Sundvall wrote: >>> >>> > In a previous license discussion I suggested the much more >>> commonly >>> > understood and more open CC-BY licence >>> > (http://creativecommons.org/licenses/by/3.0/) to be used for >>> the >>> > specification documents, but I believe the discussion then >>> slipped >>> > over to just licensing for archetypes. Can we solve this >>> while we are >>> > at it? >>> >>> >>> Well, I'm still waiting to hear from the openEHR Foundation >>> Board >>> (officially) on this issue since they are the only governing >>> body we >>> have. >>> >>> I'm not personally concerned with the notice you pointed out >>> because my >>> re-use strictly adheres to items 2&3. However, commercial >>> users/developers such as Ocean Informatics may or may not be >>> in breach >>> of that license. That is for the Foundation Board to decide. >>> There >>> does seem to be some conflict with some of the content notices >>> and >>> licenses regarding commercial use though. It basically >>> depends on where >>> you look on the website. >>> >>> The openEHR Foundation, as a legal entity in the UK (and the >>> web site >>> claims globally), supported by CHIME/UCL and Ocean Informatics >>> I assume >>> have sought proper legal counsel? >>> >>> --Tim >>> >>> >>> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> openEHR-clinical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> openEHR-implementers mailing listopenEHR-implementers at >>> openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-implementers >>> >>> >>> >>> -- >>> *Thomas Beale >>> Chief Technology Officer, Ocean >>> Informatics<http://www.oceaninformatics.com/> >>> * >>> >>> Chair Architectural Review Board, *open*EHR >>> Foundation<http://www.openehr.org/> >>> Honorary Research Fellow, University College >>> London<http://www.chime.ucl.ac.uk/> >>> Chartered IT Professional Fellow, BCS, British Computer >>> Society<http://www.bcs.org.uk/> >>> * >>> * >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >>> >> ------------------------------ >> >> _______________________________________________ >> openEHR-technical mailing listopenEHR-technical at >> openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > ------------------------------ > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > -- > > Koray Atalag, MD, Ph.D > > Clinton Bedogni Research Fellow > The University of Auckland, > Department of Computer Science, > Private Bag 92019, Auckland 1142, New Zealand > > Tel: +64 (9) 373 7599 ext. 87199 > Fax: +64 (9) 308 2377 > Email: koray at cs.auckland.ac.nz > > > _______________________________________________ > 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/20090928/4b2f7214/attachment.html>
