What is new in CWR 3.0, compared to 2.x?
Now that CWR 3.0 specifications are out, here is a brief overview of changes, and to some extent, lack of changes.
EDI and FTP - back to the seventies
Maybe it would be better to start with what is old. It is still roughly based on EDI, a format from the seventies made for 300bps modems, though the specs don’t specify that any longer. The files are to be transmitted via FTP. Yes, another protocol from the seventies. Well, at least they are consistent when it comes to the decade, but not really on how it is to be used (to be covered in another article explaining to contemporary developers how things were done 40+ years ago).
Filename in the File
Another ingenuity is the fact that the file name is now contained in the header row of the file. Such an idea can only have someone who has done no programming work since multithreading was invented. Funilly, the transmission date (according to the specs: The date that this file was transmitted to all receiving entities.) is in the same header row. So, before it is even created, it must be known when the file was delivered.
The good news is that now they specify that the default “character set” (they mean “character encoding”) is Latin1. One can now also specify and use “other character sets”, but only nine 8-bit ones specified in the lookup tables. The change from 2.x is so significant that a move to UTF-8 would be more reasonable, but it did not happen.
CWR File Types
Now there are 6 defined CWR file types. There are still transaction groups, and in most cases, one file type can only hold one transaction type and therefore one group. Although there are more elegant ways to solve this, at least things are clearly defined here.
4-digit Submitter Codes
The submitter code is now in the file and it has been expanded to 4 digits. There are reasons why separating these codes from IPI name numbers makes sense, but this still limits the number of publishers to 1.6 million worldwide. While this may seem like a huge number, compared to the current number of senders, the fact is that there are free tools that do CWR registrations, which will lead to a significant increase in the use of batch registrations.
No more ‘New’ or ‘Revised’
The difference between NWR (new work registration) and REV (revision of existing work) is gone with new WRK (Work Details) transaction. This difference did not really make sense with multiple recipients, so the change is a welcome one. This change will force the societies (and other recipients) to rely more on Submitter Work Number. This was always the best approach, but not everyone followed it.
Finally, there is a way to unregister. However, a reason must be specified, and there are only three options. While the specification states that this functionality is to be used when “recently submitted WRK transaction was invalid (i.e. filed in error)”, these allowed reasons don’t really allow unregistering with the simplest and most common reason ever: human error.
There is a huge change in this area. This will be covered in a separate article. But, briefly. there was nothing wrong with how it was specified in 2.x, except that it did not work. The new approach circumvents the reasons for that previous failure, but the question remains: Will it work this time?
This is something completely new. Now CWR allows for exchanging data on licensed usages of a work. This will be fun to code. All existing solutions are hereby obsolete. A whole new ballgame!
CWR now allows for affiliations to be territory-based. It was actually used before with repeating SPU rows, and this is a welcome change, as it will make the CWR file smaller, simpler and easier to process (and read).
Album Data is Gone
Funilly, in CWR 2.2, just recently, fields were added that provide more data about albums, only to be completely removed in 3.0. This is a welcome change, as album data is not relevant anymore, and this was resulting in repeating recording data (when the same recording was on multiple albums).
Work Code Cross Reference
A really really important new feature allows for the exchange of identifiers (work, recording, product, video).
There are many other changes, only the most relevant ones have been mentioned.
CWR 3.0 is still a totally outdated format, with many flaws, but compared to the previous version, it is better. But, the most important thing is that it will stir things up and result in new solutions and, more importantly, new approaches.