# Wednesday, April 06, 2005

I’m a bit late picking up on this, but if you are interested in either code generation, AOP, or both, check out the spec for G#Ernest Booth has come up with a very interesting spec for a new language that extends C# with some built in constructs for doing code generation.  Since these generators are extensible, etc. this provides not only some great opportunities for code gen (which I do a lot of at work) but for what essentially becomes compile time AOP.  I’ve looked a couple of times at the possibilities for doing AOP in .NET, and most of the options haven’t really been satisfactory (mostly involving remoting contexts).  This would provide most of the benefits of AOP, but happen at compile time in a happy, type-safe kinda way. 

I’ll be very interested to see if this spec turns into actual code.

Wednesday, April 06, 2005 10:09:28 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, April 05, 2005

Someone asked today how to get a list of all the namespace prefixes used in an XML document, along with their associated URIs so that that information could be used to initialize a XmlNamespaceManager.  This works…

        XPathDocument xdoc = new XPathDocument(@"c:\temp\myfile.xml");

        XPathNavigator nav = xdoc.CreateNavigator();

        XPathNodeIterator nodes = (XPathNodeIterator)nav.Evaluate("//namespace::*");

        Hashtable h = new Hashtable();



            h[nodes.Current.Name] = nodes.Current.Value;


        foreach(string name in h.Keys)





You’ll end up with a hashtable with the prefixes as keys and the associated URIs as their values.  You could probably do something even cooler with a unique set datastructure, but the hashtable works in a pinch.

Tuesday, April 05, 2005 4:12:52 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, March 28, 2005
Steve Maine’s posted a very well-written article about using duplex contracts in Indigo.  I’ve just started doing some Indigo prototyping, so any good introductory material is welcome.  It’s cool to see that they’ve come up with an obvious way to deal with two way web services conversations.
Monday, March 28, 2005 2:49:28 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
Of all the artists I thought I’d never hear of again, Billy Idol was towards the top of the list.  He’s got a new album out called Devil’s Playground, and it’s actually pretty darn good if you like that sort of thing (and I do).  Check it out if you get a chance.  It’s on Rhapsody
Monday, March 28, 2005 11:05:14 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

I upgraded to the latest 1.7 release of dasBlog CE this weekend, and it couldn’t have gone more smoothly.  I didn’t have any problems, and everything seems to be working just fine. 

Kudos to Scott, Omar and the other contributors.

Monday, March 28, 2005 10:35:03 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

I love to see technology being put to uses that actually make our lives better, so I was pretty tickled by the Fox Blocker.  It’s a little inline band-pass filter that you can screw into a cable TV line that blocks the signal for Fox News. 

Simple technology that makes our lives better.

[via Engadget]

Monday, March 28, 2005 10:01:27 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [4]  | 
# Tuesday, March 22, 2005
Travis presents some hints for understanding the Hanselman
Tuesday, March 22, 2005 3:42:44 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
I decided that KE7BJG was just too hard to say over the radio, so I decided to do something about it.  The FCC has granted my humble petition ($20.80 later) and I am now KE7PDC.  So take note, those 1–2 of you who took note in the first place. :-)
Tuesday, March 22, 2005 9:31:54 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [1]  | 
# Thursday, March 17, 2005

Here we are in the year 2005.  XML has been pretty ubiquitous for at least 5–6 years now.  Namespaces have been in use for pretty much all of that time.  And yet they remain possibly the least understood part of average, everyday XML processing. 

The bottom line is that pretty much any XML parser worth its salt these days supports the namespaces spec.  Which means that


is absolutely not the same thing as

<MyElement xmlns=”urn:runforthehills”/>

Furthermore, in line with the XML Namespaces spec, an application which is expecting the latter, namespace qualified element should not and must not process the former, unqualified element.

The XmlSerializer that we all know and love in .NET is particularly sensitive to this issue (as well it should be).  As far as the serializer is concerned, everything should be namespace qualified.  The way this commonly bites people is thus: a customer/partner sends you a schema representing the XML documents they are going to be sending you.  In the schema, the targetNamespace attribute is set with a value of “http://partner.com/schema”.  When you actually do to debug the application however, it turns out they are sending you totally unqualified XML.  Nothing will work.  There are a few pretty horrible things you can do with the XmlSerializer to try and convince it not to be such a stickler about things, most involving the XmlRootAttribute and XmlAttributeOverrides.  I can share those ways if anyone really wants to see them.  Probably best to keep them under cover.  However, that’s only likely to work if your XML document is flat, meaning that the root element only has one level of child nodes under it.  Otherwise, if you use Xsd.exe to generate your serialization class, each set of sub elements get put in their own object, which will also be namespace qualified.  And you’re back to square one. 

The right solution of course is to get your partner to send you XML that’s actually correct, but often that’s just not possible for a variety of reasons with which I’m sure we’re all familiar.  As a last ditch effort, you can pre-process the XML text before passing it to the XmlSerializer, and inject the right namespace strings.  Yucky, it’s true, but it does actually get the job done.  You will of course, be paying some overhead costs of string processing and possibly parsing the XML twice.  But what can you do?

The other thing to keep in mind is how namespaces play out in XSD schema files.  You can only have one target namespace per schema, so anything you define in that schema file will be in that target namespace.  You can import things from other namespaces, but not from the target namespace.  You can, however, define two different schema files that use the same namespace, then import them both into another schema, as long as there are no name collisions.  If you omit the targetNamespace attribute from your schema, the targetNamespace becomes “”, meaning you are defining the schema for an unqualified XML document. 

Confusing enough?  Read the namespace spec (it’s really short), familiarize yourself with how namespaces work in schema, if you see errors coming back from the XmlSerializer that look like

The element <spam xmlns=””> was not expected.

check your namespaces!  That means you are trying to deserialize an unqualified document, when a qualified one was expected.

Thursday, March 17, 2005 1:00:03 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
Scott and Rory have another funny TechEd video up.  This one’s funny even if you don't know them. :-)
Thursday, March 17, 2005 9:45:38 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  |