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:
<availability_window/>
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.
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
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?
@theorb: I'm not sure I understand you. How is specifying how long it's available different from when it expires? Aside from custom availability windows (something we need to support and aren't too keen on), we effectively want a duration for availability. We could have gone with the W3C duration standard (which I've written a parser for), but elected to use the unit/value approach. What would you have done?
And yeah, "special" is awful. We discussed providing more attributes with that (which I forgot to list), but it started to get ugly and we stopped.
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.
@theorb: Ah, I see. Actually, that doesn't work for us at all. The rights model presents and abstract view for all broadcasts. Thus, the end time varies for every broadcast, but the "availability window" for a particular rights is a constant duration, even if the times are flexible.
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').