What's In A Name?

Working on rights modeling for programmes and one of the issues deals with the availability window of online content. It might be available for a day, a week, a month, etc. It looks like this in our XML:

<availability_window unit="days" value="1"/> <availability_window unit="days" value="7"/> <availability_window unit="days" value="30"/>

The availability window is an extremely important part of our rights model and if we get it wrong, we're violating contractual agreements with people who produce content for the BBC. In short: don't get this wrong.

As it turns out, there is some content which has what is called "endless availability". This is content which, when made public, is never removed. We represent this availability window with the following element:


It turns out that this was a mistake because people assumed it meant this:

<!-- not available --> <availability_window unit="days" value="0"/>

All things considered, this was a pretty reasonable assumption, even if it was wrong. We gave this a lot of thought and considered better ways of representing "endless" availability. Here are various ideas we rejected:

<availability_window unit="days" value="∞"/> <availability_window unit="days" value="Inf"/> <availability_window unit="days" value="special"/> <availability_window value="special"/>

All of these options for an unlimited availability window were awful. That's when we saw our mistake. Just because people are calling it "availability window" doesn't mean that is what our XML element needs to be named. We now have a ticket open to rename it to this:

<!-- endless availability --> <availability_restriction/> <!-- not available --> <availability_restriction unit="days" value="0"/> <!-- one week --> <availability_restriction unit="days" value="7"/>

If you read through all of the previous examples, that new name fits quite well. Further, it's clear that without elements, there is no restriction on availability. People often name important things without giving enough though to it (I know I'm guilty of this), but a poorly chosen name can cause long-term pain.


How about

But I like the renaming better.

Perhaps instead of specifying how long it is available, you should specify when it expires? It's far easier to get that right, I think. It does still need a special value for "never", but the correct solution there is to document the semantics... and I'd also say that not providing the tag makes far more sense then providing it with no attributes, but expires="never" is the right solution, as is days="Inf". "Special" is a bad value, it doesn't tell me anything other then it isn't normal -- does special mean that it is availble forever? Only in months ending with y? Alternate tuesdays? Until it has been downloaded one million times?

I had in mind expires when="2003-02-15T13:50:05-05:00" Simple, unambiguous, and easy to work with. If I got something in the original format, the first thing I'd do is make it absolute instead of relative. Why not just furnish the absolute datetime to begin with? If it expires in three days, when does that mean, exactly? Does it expire at midnight at the start of that day? Midnight at the end of the day? N24 hours later? How does that work out when the timezone shifts -- is it really N24 hours later, or is it the same time, N days hence? The same time as when -- the time it started broadcasting originally, or the time it finished broadcasting? Of course, as I mentioned, that doesn't get around the original problem.

To my mind, missing out the availability_restriction tag more obviously means 'this has no restriction' than inserting it as a tag with no attributes (I mentally map the former to 'this has no restriction' and the latter to 'this has a restriction but I'm not going to tell you what it is').

Leave a comment

About Ovid

user-pic Have Perl; Will Travel. Freelance Perl/Testing/Agile consultant. Photo by http://www.circle23.com/. Warning: that site is not safe for work. The photographer is a good friend of mine, though, and it's appropriate to credit his work.