+1 Grahame
Sent from my iPhone On Sep 25, 2009, at 6:23 PM, 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 op > enEHR 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> 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 list >>>> openEHR-implementers at openehr.org >>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-implementers >>> >> >> >> -- >> <mime-attachment.png> Thomas Beale >> Chief Technology Officer, Ocean Informatics >> >> Chair Architectural Review Board, openEHR Foundation >> Honorary Research Fellow, University College London >> Chartered IT Professional Fellow, BCS, British Computer Society >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://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 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/20090925/47abe942/attachment.html>
