Using XmlElement in XML serialisation

Suppose you have a message definition where one of the elements can contain arbitrary XML.  The classic example is header-plus-payload; another scenario is magic cookie (an opaque blob that the receiver can return to the sender at a later date).

Now XSD has two ways of saying "anything goes here": declaring an element of type xs:anyType, and declaring an xs:any element.

The first of these surfaces in .NET as a property of type Object.  This is pretty useless, because as soon as you try to put anything into it, you get an InvalidOperationException telling you the type was unexpected and you need to supply an XmlIncludeAttribute.

The second of these surfaces as a property of type XmlElement, called Any and with the XmlAnyElementAttribute.  This is technically usable, but not very nice because there's no way to give the property a meaningful name, and because it doesn't help if the blob lives in a specific element of the schema.

So how do we get a property of type XmlElement but still have a named element of the schema and get a nice named property at the CLR level?

The answer is to use a variant of the xs:any trick, but instead of having an xs:any trying to stand in for the blob itself, you define an element which contains a sequence which contains a single xs:any.  Thus:

<xs:element name="MyMessage">
  <xs:complextype>
    <xs:sequence>
      <xs:element name="Header" type="MyHeader">
      <xs:element name="Body">
        <xs:complextype>
          <xs:sequence>
            <xs:any>
          </xs:sequence>
        </xs:complextype>
      </xs:element>
    </xs:sequence>
  </xs:complextype>
</xs:element>

This generates the following C#-level interface:

public partial class MyMessage
{
  public MyHeader Header { get; set; }
  public XmlElement Body { get; set; }
}

which is what I want.

The great questions answered

How tall is a smurf? What is the point of moths? Do penguins have knees? Actual story, less funny but still interesting, here.

Kallisti!

The newly christened Eris is already doing a fine job of sowing discord, this time amongst the brave defenders of embattled neoconservatism: "Come on! ... [They] were taking a cheap shot at world affairs. Why assume the anti-war vibe? Because of Michael Brown's own statements, coupled with the fact that he is from the California Institute of Technology, located in far west Moonbat country."

(Some debate at the Bad Astronomy Blog as to whether this is satire, but three updates from the original author say he's serious. Bless)

The planet that launched a thousand squabbles

BBC News: "The distant world whose discovery prompted leading astronomers to demote Pluto from the rank of 'planet' has now been given its own official name. Having caused so much consternation in the International Astronomical Union (IAU), the object has been called Eris, after the Greek goddess of discord." I love scientists.

Lysistrata

BBC News: "Wives and girlfriends of gang members in one of Colombia's most violent cities have called a sex ban in a bid to get their men to give up the gun." Who says the classics aren't relevant?

Office 2007 and the law of unintended consequences

The Office 2007 zipped XML file formats are undoubtedly a good thing, but they can cause problems when clever software "understands" that you're using ZIP as a compression format. A couple of issues I've run into so far...

MailMarshal recognises Office 2007 files as zip files and checks inside them. Now some of the XML streams inside an Office 2007 file have filenames like presentation.xml.rels. When MailMarshal sees this, it goes "Oh no! Double file extension! Must be evil scripting virus!" I'm sure other mail cleansers have similar rules. So emailing Office 2007 files around is a bit of a lottery at the moment. (Mind you, this rule also bites people who version their files, e.g. "Design Document v0.8.doc." But you can change filenames, whereas you can't change the Office 2007 file format.)

Typepad recognises Office 2007 files as zip files containing XML. Fortunately, it doesn't unpack them, which is something it does under other circumstances, but it does seem to look inside them to figure out what how to serve them up as, and unfortunately ends up messing up either the content type, content disposition or both (I can't be bothered to do a proper diagnosis). So if I post an Office 2007 file here, and you click on the link, your browser may think it's plain text intended for display, and show you all sorts of garbage. In fact the file is perfectly intact and can be downloaded just fine.

I'm sure that as the Office 2007 formats become more widespread, zip-aware products will become equally Office-aware and these problems will go away. In the meantime, the effect of using a so-standard-it's-transparent packaging format is an interesting example of the law of unintended consequences.

LINQ presentation slides

Slides from the .NET user group presentation in Wellington last Wednesday.

PowerPoint 2007 format (104K) (Warning: Typepad serves this with a bad MIME type which may cause your browser to try to display the binary data as text. If you run into problems, try right-clicking and saving locally.)

PowerPoint 2003 format (1MB, may have some formatting glitches)

XML, data and regularity

Alex James warns that XML is tomorrow's COBOL: "XML is cumbersome, we do a lot of work to get our database records into XML format, we do a lot of work when we modify it, and finally we do a lot of work to get it back into a database."

XML is a victim of its own success. XML is an excellent format for documents, from traditional documents such as XHTML pages, XSL-FO renderings, DocBook manuals or even insurance policies to more abstract descriptive documents such as the CML description of a molecular structure or the XAML rendering of a heterogeneous object graph (typically a WPF visual or a WF workflow, but could be anything; I've used XAML to mark up business logic).

What these have in common is that there's not a lot of regularity to them. An XHTML page has huge freedom to intermix text runs, bold elements, headings, images and so on and so forth. The same applies to something like DocBook. My business logic XAML listed components each of which could have its own configuration schema. Try to create a pseudo-relational structure for these, as Alex does for his "list of books" XML, and it would be a nightmare. XML succeeds in these cases precisely because it provides the structure inline with the content.

Once you move out of this realm and into the realm of highly structured data, such as Alex's list of books, the inline structure becomes a weakness not a strength. The repetition of the structural information against every element creates bloat, and more worryingly it creates duplication. I don't really want to admit the possibility that one of my books might have an "Authro" instead of an "Author". So for strictly schematised data, a representation that carries the schema only once, and implicitly associates content to schema in some way, is safer and more efficient. Alex proposes a tabular representation. This works fine for tabular data, as you would expect. When hierarchies enter the picture, however, he has to reintroduce relational complexities like keys and joins to make it work. Of course, it does still work, because it's just the relational model. Nevertheless, it isn't as natural as a true hierarchical schema, but I'm not sure what such a schema would look like, and that would reintroduce the issue of mapping in and out of relational databases.

For the time being, then, XML is being wildly overused, and many if not most applications of XML would be better served by Alex's vision of transporting mini-databases around. But it's unfair to blame XML for not being a relational database, just as it would be unfair to blame the relational model for being a lousy way to represent documents.

Cool Earths outside Hot Jupiters

BBC News: "One of every three known planetary systems could harbour Earth-like planets in habitable zones further out than the Hot Jupiters." I wonder what the inhabitants of such a world would see in their sky, what kind of mythologies it would inspire and how it would affect the development of astronomy and philosophy.