"One-Time Pad" is more a concept than a strictly-defined algorithm. If there was a specification of an "OTP encryption algorithm" (say, in RFC format or similar), which tells where each byte goes and when, then that specification would tell you what happens when the key length does not match the data length. Moreover, if, in the case where the key is shorter than the data to encrypt, that specification told you anything else than: "if the key is shorter then encryption must be aborted"; then that specification would not qualify as a true implementation of the "One-Time Pad" concept.
In that sense, there cannot be any "key wrapping around" for a One-Time Pad because then the "pad" (i.e. the key) is no longer "one-time".
An OTP algorithm specification would be quite simple, but there is still room for variants. When the data to encrypt is a sequence of bits (as is typical in computers), then it is customary to talk of the OTP with XOR as operation for encryption and decryption. However, any group operation can do the job. For instance, if the data is a sequence of octets (aka "bytes"), as is also very typical in computers, then you can do an OTP with a byte-by-byte integer addition (modulo 256), while decryption would use subtraction. This also works well and fulfils the One-Time Pad concept. Many pre-computer uses of OTP (with papers and human brains) worked with letters, in which the operation was mathematically equivalent to addition modulo 26 (the underlying group being, in that case, Z26, mapped to the A to Z letters).
I am not aware of any established, well-defined specification for a computer-based one-time pad, because, let's face it, for practical usages one-time pad tends to suck. We can find traces of the OTP concept in some degenerate cases (for instance, ElGamal encryption can be mathematically described as a Diffie-Hellman key exchange resulting in a shared key, which is then used to encrypt the short message to send with a custom one-time pad operating in the same group as the DH part).