Consistent way to define document title, subtitle, author, affiliation, abstract etc
There are really two questions here: how to define the interface and how to implement it. I'll only tackle the former, because the implementation would require several hours' work.
First you have to decide whether using non standard commands, say \Title and \Author instead of \title and \author. There are many classes around and different realizations. For instance, the standard classes (article, report and book) allow for only one \author command, others want that different authors go in distinct \author commands (amsart does this).
I'll assume you go with \title and multiple \author commands for maximum flexibility. The best approach is, in my opinion, using a key-value syntax.
A document always has a title, and sometimes a short title for the header or a subtitle. I would do it like
\title[
subtitle=A subtitle,
short-title=A short title
]{The very long title of this document}
rather than providing a bunch of commands such as \subtitle and \shorttitle: in this way all the data are in one place. Similarly for author information:
\author[
affiliation=University of Someplace,
affiliation-secondary=Institute of Silly Investigations,
address=42, Hidden Road, Someplace,
[email protected],
[email protected],
abbreviated-name=A. Uthor,
thanks=Research grant 1234567890,
]{Abigail Uthor}
\author[
key=writer,
corresponding,
affiliation=University of Nowhere,
[email protected],
long-name=Winfried Riter,
]{W. Riter}
\author[
share=writer,
[email protected],
]{B. C. Dull}
Note that I used several keys that can be used or not by your class. For instance, key=writer could make it possible to share affiliation information between two or more authors. The more detailed and classified is the information, the easier will be to implement a set of commands that process it.
Talking of user interface, something like \AtBeginDocument{\maketitleandabstract} is surely not something document authors should be supposed to type. This will be done by the class; the classical approach with \maketitle can be used too.
I'm also keen towards placing this information after \begin{document}. If you do it in this way, you can free yourself from the burden of adding the \maketitle command: just define a articledata environment, whose end automatically issues \maketitle. So
\documentclass{myclass}
<packages>
<definitions>
\begin{document}
\begin{articledata}
\title[...]{...}
\author[...]{...}
\author[...]{...}
\abstract{
this is the abstract
}
\keywords{
a list of keywords
}
\end{articledata}
<paper starts here>
\end{document}
With a simple switch you can warn that commands such as \author, \title, \abstract and so on must go in the articledata environment (or issue an error message). It will be also easy to provide a package with a compatibility option that redefines the commands and the environment so that the document becomes compatible with article.
I have a class that does this. It is imaginatively called myclass. I wrote it out of frustration with journal classes all having different ways of wanting the same information. The reasons why are:
I rarely know which journal I am going to submit to when I set out writing my article. So customising it to fit the journal is something done at the end.
Sadly, I often end up submitting an article to several journals. It's always a bit ambiguous as to whether or not they should be submitted in the "house style" and in my early days I'd put it in the house style just in case. But changing journal style can involve large changes to the document so having a more "plug and play" method makes sense.
It's not uncommon to have several versions of the article on the go: one for submission, one for the arXiv, one for some other repository; and each will have its own idiosyncrasies. So being able to change one option makes life that much easier.
Unfortunately, journals don't just supply a class. They also tend to supply a load of "helpful" macros. These often conflict with my own macros - but since I didn't know which journal I was going to submit to at time of writing, I don't want to think about these conflicts at time of writing. Ideally, I don't want to think about them at all.
The underlying ethos is this: when writing my article, I want to be able to make use of all the things in LaTeX that make it easy to write an article. Thinking about which journal I'm going to submit to conflicts with this. But once I've written the article then I don't want to waste a lot of time (and it really can be a lot, due to point 4 above) changing everything.
My class is not very elegant or sophisticated. It was written long before I happened on this site and I've learnt a lot since then. So I'd probably do it all differently now. Nevertheless, it stands as an example.
(Incidentally, some journals have really weird ways of accepting input. Getting them right was ... difficult.)
As for why a class and not a package, it makes the interface easier. All I need to do is change one option to my class. If I made it a package then I'd have to change the class and probably some options to the package. Too much work!
This question did come to my mind several times. But, I would never even dreamed to attempt a general solution. Thinking about it led to similar concerns as expressed by @tohecz. But, looking at @egregs solution inspired me to extend it.
The problem which remains is that an interface with with a finite set of commands to gather meta data won't be able to cover all cases. Hence, an ideal interface must be able to provide a command that allows users to create custom metadata-commands, such as '\newmetacmd', one that can redefine the existing ones, and one to rudimentarily restyle the appearance. With this approach the problem arises of how to include the information of the custom commands to the title. (If they are custom they can't be coded into \maketitle beforehand. Well, there would be a possibility, but it is very limiting...) My idea to solve this consitst in considering every collection of information coming from one macro, e.g. \title[...]{...} as one block. So, the \title macro will produce something like \block1 behind the scenes. All these blocks/chunks will be gathred at the end of a articledata (or maybe documentdata) environment using a loop. The ordering will be determined by the emergence of the \newmetacmds (or better \newttlblocks) in the preamble, and it will be influencable somehow - also regarding the predefined commands \title, \author and \date. In detail it would look like
\newttlblock[integer]{newinfo}[kv1][kv2][kv3][kv4]
(where the integer parameter gives the ordinal position of the block; if empty, it will be the next one after the last block) which than would be used as
\begin{docdata}
\title[...]{...}
...
\newinfo[kv1=...]{...}
\end{docdata}
As addressed further up, there would be something like
\ttlblocksetup{newinfo}{<space below>}{<alignment>}{<font>}
and also
\renewttlblock[<n>]{title/author/date}[kv1][kv2][kv3][kv4]
Funtionality could of course include the usage of multiple authors (pointing to AMS classes) too.