Completely move to GitHub

[koppor]

I very welcome the resurrection of BibTeXML. See also JabRef/jabref#938.

Currently, there are many legacy things pointing to sourceforge. I would propose to completely move to GitHub:

1. Create a homepage on GitHub
2. Change the namespace of the xmlschema to https://bibtexml.github.io or to https://github.com/Zearin/BibTeXML.

I would propose to create a "bibtexml" organization on GitHub allowing http://bibtexml.github.io. Furthermore, there could be multiple repositories. One for the schemas and simple scripts; and one for the java code.

I can support if you want.

[djcomlab]

It would be great to resurrect this project - but looking at the commits it looks like @Zearin may not have worked on this for a while (last commit 3 years ago?).

The JabRef thread you reference shows there's some interest in keeping the project alive. If we could move it to an org that might help kickstart things, but only if there's enough people who are willing to contribute to maintain it. I'm happy to help, as I've used BibTeXML (but not this code) in one of my own projects.

[koppor]

I am not sure whether we should drop BibTeXML completely and move to RDF. http://data.bibbase.org/ontology/ seems to be promising. There are also other ontologies available: https://www.w3.org/wiki/ConverterToRdf#BibTex. It seems, there isn't a clear winner, is there one?

[djcomlab]

The argument for keeping it going would be if there are people using it. Although on the Github project there's not many stars and no forks yet, the Sourceforge project is still serving a lot of downloads of the OSX converter (60+ in the past week)...

[Zearin]

Although I haven’t worked on this project in a long time, I still would love to keep it alive. Honestly, I thought I was the only person who still knew about (or cared) about BibTeXML. (Thanks @koppor, for proving me wrong! ☻)

My vision for BibTeXML was to eventually make it completely driven by XProc+XSLT. I would prefer to keep Java code out of the source for this project if possible.

The XML community isn’t what it was 10 years ago, and so it’s very likely that the only things that will ever run XProc or XSLT are Java-based anyway. My goal was to provide maximum customizability for input, processing, and output. I had planned to offer this customizability via options in higher-level XProc scripts, which would call the lower-level XSL files.

What do you think?

[djcomlab]

I think it's a pretty good idea to try use as many XML technologies as possible here and then language-specific APIs can probably all reuse the same XProc/XSLT.

But I guess the question for this project is a question of scope - do you want to make this just about the XML, or also about language-specific tooling around it, such as creating Java or Python APIs? When you look back to the original SourceForge site, what people are really downloading and presumably using is not the XML and source, but the BibTeXML Converter package (https://sourceforge.net/projects/bibtexml/files/?source=navbar).

[Zearin]

I think it's a pretty good idea to try use as many XML technologies as possible here and then language-specific APIs can probably all reuse the same XProc/XSLT.

Good!

(Everyone talks about not reinventing the wheel, but it happens so often in spite of that.)

But I guess the question for this project is a question of scope - do you want to make this just about the XML, or also about language-specific tooling around it, such as creating Java or Python APIs?

For this project, I would like it to about just XML. I’d be okay to also include some thin bash executables for conversion.

However, if there is demand for it, @koppor suggested a BibTeXML organization. That organization could then be the home for other projects, each of which uses this repository as a library for building whatever they want.

What does everyone think of this?

When you look back to the original SourceForge site, what people are really downloading and presumably using is not the XML and source, but the BibTeXML Converter package (https://sourceforge.net/projects/bibtexml/files/?source=navbar).

That’s why I first downloaded it! :D

[koppor]

I have been recommended MODS - the Metadata Object Description Schema. It is actively maintained and bibutils offers conversions to/from bibtex. A short intro about MODs is provided at https://sourceforge.net/p/bibutils/home/Working%20with%20MODS/

I currently lean towards moving away from bibtexml support and fully supporting MODS even though the JabRef team invested energy on a better support for bitexml at JabRef/jabref#1666.

[koppor]

I just read the biblatex manual and found "biblatexml".

When biber either reads or writes biblatexml format datasources, it automatically writes a RelaXNG XML schema for the datasources which is dynamically generated from the active biblatex datamodel. There is no static schema for biblatexml datasources because the allowable fields etc. depend on the data model.

I think, focussing on bibltexml tooling should be the way to go as there is already a biblatexml community. How much effort is it to port the bibtexml tooling to biblatex? Maybe, biber already does much of the things?

[koppor]

I found this issue while cleaning up JabRef's code using JAXBContext.newInstance as Basis for XML Parsing. Think, we now have different format (either MODS as stated at #1 (comment)) or even Citation Files using YAML.

Even though XML tooling was (somehow) technically great, people moved on...

Thus, I close this issue and say "farewell" to BibTeXML.