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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090925/a824b466/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: OceanC_small.png Type: image/png Size: 4972 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090925/a824b466/attachment.png>
