Ian Davis shows how even the smallest RDF graph has multiple XML serializations. He missed some variations: (i) rdf:RDF is optional, and (ii) rdf:type has special-case treatment in the grammar (iii) XML base can interact with URIs.
This variety should not be suprising. A good question to ask here, is how much we’d gain from dropping the more esoteric syntactic variations. Imagine for example a syntactic profile of RDF/XML in which rdf:RDF was never needed, rdf:type and literals were never represented as attributes, node elements always (or never!) carried a type, and rdf:nodeID was only used when absolutely (how to define this?) necessary. I still suspect that there would be plenty of variation, because the fundamental practice wouldn’t change. We’d be representing unordered graph data over an ordered tree.
My take: custom syntactic profiles, ones designed for some particular community and purpose have a role. We can define them as RDF/XML subsets (in Relax-NG, Schematron or prose), or as non-RDF XML formats, transformable with GRDDL. Either approach makes life somewhat easier for those working with XML tools, at some cost to those in an RDF environment. But we should also stop looking over our shoulder at XML. RDF/XML is painful for XML developers because they find themselves lacking familiar tools when working with RDF.
This is not because of the particular charm of those tools, but because they exist. If the RDF programming environment were anywhere near as rich with tools as XML’s, this would not be such an issue. Developers are pragmatic, and will use what is available. If RDF tools feel less mature than XML tools, developers will naturally complain if their data formats force them to use only RDF tools. SPARQL is an important thing here, one that might be accompanied by lightweight API standardisation and other steps to lessen the pain of those moving on from pure-XML toolsets.
I’d much rather see folk work on RDF tools and APIs (how about a SPARQL engine in .js or PHP?) than this endless navelgazing on RDF’s XML syntax. This is not to downplay the excellent work that’s already out there (Redland, Jena, etc.), just to note that we’ve still some catching up to do with the XML world. We don’t yet have API portability between tools, beyond that offered by the (still draft) SPARQL spec. It’s that sort of thing that inspires confidence in developers, and that will give them the sense that maybe (just maybe…) they could work with a non-XML toolset. Given a choice between worrying about the flexibility of the RDF/XML syntax versus helping test and document SPARQL support in some RDF toolkit, I know how I’d rather be spending my time…