MVH Solutions is based in Cavaillon, a market town close to Avignon in the South-East of France.
MVH Solutions is an "entreprise unipersonnelle à responsabilité limitée" (EURL). This is the French name for a limited liability company with a sole owner. The company was registered in Avignon in 2011.
Typically the organisation that pays for it. However, MVH Solutions encourages code sharing, especially via open source licences.
As a French company, MVH Solutions accepts Euros. However, it is possible to transfer funds in other currencies such as US dollars or British pounds. The easiest means of payment is bank transfer, but Paypal and French cheques are also accepted.
Mark studied sciences at school, obtaining A levels in physics, chemistry, biology and computer science. He obtained a BSc Hons (2i) in psychology from Surrey University, including an industrial year working as a programmer at the Admiralty Research Establishment in London. He received a prize for his dissertation on how users reason about complex computer systems.
Mark has a Masters in Applied Theology from Spurgeon's College, London. His dissertation was one of the first explorations of virtual Christian community.
He has a certificate of French language proficiency (C1) and of French Sign Language (A2).
Mark moved to France in 1990 to set up the French branch of OAC Ministries. This involved outreach and training in French-speaking Europe. During this time he published training materials which have been translated into many languages. After this he ran a cybercafé in Cavaillon. During this time he was involved in various Internet projects, including Church of Fools and St Pixels.
Mark has written two theological booklets for Grove Booklets.
He has contributed to three technical papers at the XML Prague conference
Mark was born in Lancashire, Great Britain. He has lived in France since 1990 and has dual French-British nationality.
The short answer is "the one that works with your ecosystem".
In 2020, USFM is the most popular format for the creation of translations. It is supported by the largest Bible translation organisations and is at the heart of Paratext. Its character-based markup approach, while dated, is easily learned by non-technical users, including those who have learned to read in order to participate in translation projects. However, it is awkward to process using modern toolchains, and the specification is ambiguous in places.
USX is essentially USFM expressed as an XML vocabulary. It is used by the Digital Bible Library and by consumers of DBL data including YouVersion and API.Bible. It also supports machine-readable Scripture references which are not available in USFM. Its big benefits are roundtrippability with USFM and processing options using standard XML tools. It is not designed to be edited by hand and is not a particularly rich XML vocabulary (because of the need to roundtrip with USFM).
OSIS was intended to replace USFM. It is a rich XML vocabulary that is still used for Bible translation and publication. However, the specification has been criticised for being over-complex and under-constrained, with the result that there are often several different ways to express the same text.
That's always an option, which has been tried by many organisations and - who knows? - maybe your format will become the future of Bible translation and publishing!
However, experience shows that it is remarkably hard to come up with a relatively simple format that can handle all the variation that exists in the world's Bibles. Most new "v1.0" Bible data formats make the easy things easy and the hard things impossible. Hard things here include verses and chapters that may be out of order, may not start at 1, may not be numeric at all and may spread over multiple paragraphs. In most cases it is well worth seeing whether one of the standard formats can work for your application.
Emacs. That's partly because Mark's first programming job was on a Lisp machine with Zemacs, and partly because Emacs copes well with large XML documents. (It's also partly because VI is horrible.)
Lisp is really cool. Unfortunately, it was popular when computers of the time struggled to run it efficiently, and today it lacks support for a lot of modern protocols. C++ can be quite cool too, as long as you get to pick the bits of C++ to use, and as long as you never have to maintain anyone else's code. Relatively inefficient C++ can look a lot like a dynamic programming language but still run 20x faster, and that's a game changer for some applications. FORTH seemed like a great idea in the 1980s. (I did write a complete Bible toolchain in a FORTH-like language. I probably won't do that again.)