My first coding experience with CWR 3.0
Django Music Publisher 19.7 (July 2019) has several features that implement CWR 3.0:
- Generating CWR 3.0 Claim Submission Files (aka Work Registration Files)
- Generating CWR 3.0 ISWC Allocation and Resolution Services Submission Files (aka ISWC Request Files)
- Syntax highlighting for CWR 3.0 (shown in the screenshot above)
- Basic CWR 3.0 ACKnowledgement parsing with remote work ID import
It is open-source software, so anyone can test it and examine the code. Well, it does require certain tech skills, maybe not anyone… but let’s not nitpick.
CWR 3.0 implies a different data structure in publishing chains and related to writers. Django Music Publisher is a tool for a single original publisher, and for the time being, I decided not to include multiple affiliations. So, no changes there, except that affiliation data moved from SPU, SWR, OWR to SPT, SWT, OWT records.
No Product Data
The other major change is that album (product) data is gone. It also implies that societies don’t use this data any longer, or maybe never really did. The new CWR generation code in Django Music Publisher, that includes both 2.1 and 3.0, also ignores album (product) data.
CWR 3.0 Syntax
So, once it was all done, and both versions of CWR were ready, it became clear how much more readable is the new version. This got me thinking about including some basic highlighting in the open-source code. In the end, I chose to include the bare minimum, names and titles, as well as internal IP codes and chain sequences. And, of course, shares. It can not really replace my Visual CWR, currently available only for 2.1, that provides far more details about all fields. But it is far more than bare black-on-white CWR output.
I love the addition of XRF records. Even the simplest software that deals with registrations of musical works must hold some data about data of other parties about the same work. In the case of Django Music Publisher, work identifiers used by societies and administrative agencies, extracted from acknowledgement files. This opens a new world for CWR use and I am sure I will write several articles about this. Eventually.
Well, strictly hypothetical, for the use needed for Django Music Publisher, the difference is minimal. ACK records have one additional field, which I chose to ignore for now. I do realize that dealing with conflicts and other issues can not be ignored, but I think that programming it without real experience in dealing with societies by CWR 3.0 would be meaningless.
I wrote a separate article about this subject, regarding Django Music Publisher, the request generation is done. Response parsing is not. I will deal with it when the first responses start coming in. It should be a simple task.
It is still early for any conclusions. CWR 3.0 is out. It is better in many ways. It will require some major changes in existing solutions, which will give new ones a better chance. But so much depends on the way societies will implement it.