My first coding experience with CWR 3.0


CWR 3.0 with syntax highlighting in Django Music Publisher

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.

Data Structure

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 Ownership Shares

There is, however, one change that could not be overlooked. Previously, the sum of ownership shares had to be 100%, but the sum of collectible shares per territory could be less. With ownership shares gone, now the sum of collectible shares must be 100% (or 0) for any territory. So, OWT records must be used. And, non-controlled writers not also have PWR records, which also includes the number of the publishing chain. It took me a couple of days to figure out some edge cases like co-publishing. An inconsistency in the documentation did not help.

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.

Acknowledgement parsing

Well, strictly hypothetical, 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.

ISWC handling

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.