Assuming all the boring namespace setup, consider the following chunk of RDF to describe a person and their phone numbers:

<rdf:Description rdf:about = "x-urn:aaronstraupcope:knows:who:~foobar">
 <rdf:type rdf:resource = "http://xmlns.com/foaf/0.1/Person" />
 <vcard:TEL>
  <rdf:Bag>
   <rdf:li rdf:parseType = "Resource">
    <rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#home"/>
    <dc:identifier rdf:resource = \
       "x-urn:aaronstraupcope:knows:phone-number:~123.456.7890" />
   </rdf:li>
  </rdf:Bag>
 </vcard:TEL>
</rdf:Description>

Similarly, consider a second chunk of RDF to describe an organization and it's phone numbers:

<!-- observant readers will note that this is not really
     a list of phone numbers and that if it was the
     code used to query it (below) would fail. but that's
     just syntax and doesn't change the fundamental point -->

<rdf:Description rdf:about = "x-urn:aaronstraupcope:knows:who:~workplace">
 <rdf:type rdf:resource = "http://xmlns.com/foaf/0.1/Org" />
 <vcard:TEL rdf:parseType = "Resource">
  <rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#work"/>
  <dc:identifier rdf:resource = \
     "x-urn:aaronstraupcope:knows:phone-number:~555.555.1212" />
 </vcard:TEL>
</rdf:Description>

So, if it's known that :~foobar works at :~workplace it stands to reason that there's no reason to write the same thing twice. Rather, the correct approach would be to reference the latter's work phone number in the former's work phone definition.

There doesn't appear to any way to do this RDF; specifically to reference a discreet subset of another resource's properties. I was able to find a proposal descrbing a fragment identifier syntax [in] RDF but it is only a proposal and already three years old.

More importantly, my own needs for this kind of data involve being able to process it with XSLT. No, I haven't had a sudden change of heart about RDF/XML, but judicious use of xsl:template match = "..." has made it suck just a little less.

Enter XInclude. The following is valid RDF that doesn't really help you connect the dots in a directed graph context but since you can't do that anyway, it doesn't cost you anything either. On the other hand it makes managing, and rendering, disparate but related pieces of data easier.

<rdf:li rdf:parseType = "Resource">
 <xi:include xi:href  = "x-urn:aaronstraupcope:knows:who:~workplace"
             xi:xpointer = "xmlns(r=http://www.w3.org/1999/02/22-rdf-syntax-ns#) \
                            xmlns(f=http://xmlns.com/foaf/0.1/)xpointer(*// \
                            r:Description/r:type[@r:resource= \
                            'http://xmlns.com/foaf/0.1/Org']/following-sibling::* \
                            [name()='vcard:TEL']/r:type[@r:resource= \
                            'http://www.w3.org/2001/vcard-rdf/3.0#work']/parent::*/ \
                            child::*)" />

 <!-- I am still trying to figure out why IsaViz spazzes out
      when I add a xi:fallback directive -->

</rdf:li>

You may want to poke your eyes out after looking at that for too long but, then, nothing's for free and it's the kind of hairiness that could fairly easily be hidden by a GUI client. It goes without saying that the query itself could be optimized.

If, like me, you are using URNs as URIs you'll need to add corresponding rewriteSystem entries in your catalog.xml file so that the XInclude processor is able to resolve the path to the resource you're pointing to.

<rewriteSystem systemIdStartString="x-urn:aaronstraupcope:knows:who:~"
                   rewritePrefix="file:///path/to/you/know/who/" />

Later: the following fixes the bugs described above and doesn't care whether or not phone numbers are wrapped in a rdf:Bag container. It also makes sure that only telephone numbers for a specific resource are included, in case there are multiple resources defined in a single document:

<xi:include xi:href  = "x-urn:aaronstraupcope:knows:who:~workplace"
            xi:xpointer = "xmlns(a=x-urn:aaronstraupcope:knows:who:~') \
                           xmlns(r=http://www.w3.org/1999/02/22-rdf-syntax-ns#) \
                           xmlns(f=http://xmlns.com/foaf/0.1/) \
                           xpointer(*//r:Description[@r:about= \
                           'x-urn:aaronstraupcope:knows:who:~workplace' \
                           ]/child::*[namespace-uri()= \
                           'http://www.w3.org/2001/vcard-rdf/3.0#' \
                           and local-name()='TEL']/descendant-or-self::*/ \
                           r:type[@r:resource='http://www.w3.org/2001/vcard-rdf/ \
                           3.0#work']/parent::*/child::*)" />

I will post these stylesheets in the next day or so...

I have posted an XSL stylesheet for, more or less, converting XHTML 1.1 to the Atom syndication format.

I did this because as much I find the whole Atom thing extraordinarily tiresome I find all the hand-wringing from the RSS weenies even sillier. And given a chance to piss everyone off, I often jump.

I post this only as a public service . I have zero interest in maintaining this for anyone but myself. If you want to use it as fodder for a general purpose library, please be my guest.

I haven't bothered to remove private function calls and there is no documentation. However, there are comments enough for anyone with an understanding of XSLT to follow.

Update: this post generated much more interest than I anticipated so, for the curious, some background which has absolutely nothing to do with Atom (except maybe that Atom's content model maps better to my way of doing things than any of the various RSS efforts) :

The XHTML in question uses my shiny new weblog format which I wrote as a way to store all the data for a post in a static file. All the data but no form; foofy design stuff is added after the fact using, in my case, XSL . There are reasons why I didn't choose another, perhaps more expressive, XML application which will become clear below. I still use a database because it's faster for generating things like indexes but it is not considered authoritative. That is, the database reads from the flat files and not vice versa.

(It also lets me fob off the versioning problem on CVS and worry about other things.)

The single capital-R rule I've learned farting around with increasingly complex ways of generating this site is : the only thing you can count on is the web server being able to send plain vanilla HTML files — everything else will break. The only question you have ask yourself is how much pain will it cause and how much time you want to devote to fixing the problem.

Storing everything as XHTML and wasting a couple extra computrons on XML and XPath munging may not be pretty but when everything else fails at least the content is just there .

Meanwhile, this is sound of me adding a buzzword-bingo [meta] category to list all the damn acronyms used in any given post...

The version number only reflects the fact that the documentation is incomplete. Let the bug reports begin...

Update: Well, this proved to be a pretty trivial task. I have munged about 98% of a maximal Atom feed into RSS 1.0. I don't expect the multipart content feed or the RSS 2.0 stylesheet to be anymore complicated. I guess I will try and post all of this tomorrow morning.

Up your date: So, it's all done. Save the widget to convert a W3CDTF date string to a RFC822 date string which is making me feel, well, funky. Fortunately, someone else has already done most of the heavy lifting . Oh yeah, and some kind of kludge to deal with the fact the XSL spec seems to be seriously brain-dead when it comes to generating <![CDATA[ ]]> sections. But not tonight — there is a hockey game to watch...

Is that a date in your pocket? Steve Ball is my hero, even if the markup:cdata-section template is broken. And it goes without saying that the logic for fussing with dates in RSS 2.0 will result in bug reports. Life sucks — but often less than date processing. I will finish up some rudimentary documentation and post a tar ball this afternoon (Sunday.)

Please god, can we find something else to argue about now?

Not much of interest has happened during the last week.

Unless you count the spat over XML error handling, which I don't. It was a controversial decision : I'm shocked! It's been borne out to be a good decision, HTML notwithstanding : Shocked, I tell you!

I briefly considered posting an open letter to television news executives imploring them to let, no force, their on-air personalities to wear toques when it's - 40° Celcius outside. If not for their sake then for the impressionable young children watching them.

A bunch of stuff got upgraded on the machine that serves as the staging server for this weblog and now the fancy-pants program that does all the heavy lifting, generating pages and indexes, is dumping core whenever the XSLT function aa:permalink() is called. I leave it as an exercise to the reader to find the Deep and Meaningfuls in that one.

I'm not overly concerned about this, right now. It will get fixed but I'm not going to turn my life upside down over it. And some pretty awful stuff has happened in the neighbourhood, recently, that helps keep things in perspective.

In the meantime, this is one of the best stories I've heard in a long time:

“You killed my girlfriend's fish. No, you made her kill her fish.”