Surfin' Safari

Prompted by a conversation with Brian "NoBull" McCauley at YAPC::Europe this year, where he said he hasn't been buying any new books since he signed up for the Safari Online Bookshelf, I decided to ask at work about the possibility for getting a corporate licence for Safari.

Unfortunately, Andreas was not too excited about it. His arguments made a little sense, though; he said he wasn't against buying books and that if someone asked for book X to be purchased, he'd generally agree to do so. He also said that this way, the company knew better what people were reading about and which books were available in the company if other people wanted to refer to them (and they could also control things better: if someone wants a book on a way-off topic that's not connected with their current work, they can more easily say no or ask about it).

He was a little afraid that if everyone had, say, ten books available to them per month and swaps them out every half year or so that the time taken reading those 20 books a year might cost more in loss of productivity than is gained by the increased knowledge and the greater flexibility in purchasing books; that it might be better to buy, say, five (or even ten) good books a year per employee rather than have them spend company time reading books that aren't directly relevant but only interesting (since the temptation is bigger to add another book to your shelf than to ask for the company to order a paper book, which'd require someone's signature or at least approval).

So I'm not sure. He said, for now we'd stick with ordering paper books, but if a good case (cost/benefit analysis, or whatever) could be made that includes the time spent reading these many books available, he might be persuaded.

The gems one finds in specifications

From the Errata to the XPath version 1.0 specification:

[…] The namespace URI component of an expanded-name is implementation-dependent if the expanded-name is expanded from a QName whose prefix is declared by a namespace declaration with a namespace name that is a relative URI (with or without a fragment identifier). […]

Um... I don't think I understood that nested statement. "If a foo is a bar whose baz is a qux that is blech…"—I think my context stack overflowed.

Testing span

Testing code without anything.

Testing code using class="foo".

Testing code using id="bar".

Testing code with another class="foo".

Testing code using another id="bar".

Edit: the id="bar" is indeed filtered out.