General discussions.

[lanceXwq]

I just want to open this issue as a place for general discussions, such as the packages we want to use and the functions to be realized. If we feel like having these conversations somewhere else or in person, this thread can serve as a record/checklist.

[harrisonlabollita]

Sure! Hopefully, you see the general idea of what I'm going for with the basic functionality. I created a pull request in LightXML.jl to add that basic function I wrote to find all the elements instead of just a single one. This is a functionality that all of the other xml parsers in other languages have so it seems like it should be built into this package as well. Anyways in my head the workflow with this package would be from the REPL to make a search (however coarse or fine you want that search to be) and then the results of that search should be saved to a bib file with all of the results from that search in bib format with the Information neatly organized and ready to go. This is the ideal case for now. We will see if it needs to be refined from there.

[harrisonlabollita]

Have a working function. Try it out. The next big task to do will be to dress up the search features so that you can pass as little as much information as you want into the request. This will be the tricky part.

[lanceXwq]

Please check my fork for some of my commits, haven't created any pull request since I want to discuss the following with you first.

Some stuff we may add:

1. Add support to bioRxiv, this may not be an elegant addition since the URL format looks quite different.
2. An option to rename the output bib file.
3. Append instead of rewriting if the bib exists.
4. If we decide to do 3, then probably we also need to search for repetitions.

Some nitpicking:

1. I've been using julia formatter to format my code, would you like to use it as well, or would you rather stick to your current style? (See my fork as a comparison.)
2. The naming convention is inconsistent right now, some functions use underscores (find_all_elements) while some use camelCase (extractBibInfo), probably it's better to pick one. Here is the recommendation from the manual. Same thing for the variables.

[harrisonlabollita]

I checked it out the code looks nice. I’ll have to add that JuliaFormatter to vim it looks like really nice. I think we can go ahead and merge this. I’ll clean up variable names, etc., and also check out the Julia best practices that you had sent along.

Thanks for this

[lanceXwq]

I've been thinking about this for a while, but don't really have time to try it. Remember we want to allow some logic operations on fields (author, title, etc)? Maybe we can imitate the way how open is defined in Julia. Since it can take both keyword args such as read = true, write = true and "mode" args such as "r+". In our case it can be author = true, title = false and "au-tl".

[harrisonlabollita]

I like this! Almost like designing a shorthand. Something like you said au-ti-… -> author = true, title = true, etc. I’ll give it a try!

[harrisonlabollita]

I think if we add this feature that we were talking about previously this would be in good enough submit this as a package on the JuliaRegistry.

What do you think of this:

request(search_term, field="author title ... year, etc")

where the field is a space separated string. This string then gets split and passed through a dictionary that maps the field names to the keys that are then thrown to the arxiv API in the format that it wants.