# Friday, 29 October 2004

The last working day before Halloween is upon us (as evidenced by the giant Sponge Bob sitting over in QA) and Drew brings us a poem of distrubed systems horrors.  A great read!

Friday, 29 October 2004 09:44:02 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 27 October 2004

So, one the things we do in CERT (Community Emergency Response Team) training is simulated disaster exercises.  One of the things you need for simulated disasters is simulated victims.  What you want from a good simulated victim is something that looks realistic, and preferably really gross.  If you get used to dealing with simulated grossness, the theory is it will be easier to deal with actually grossness when it shows up. 

Enter "moulage".  (I'd never heard that word either.)

"Moulage" is the art of making people up to look like they have horrible disfiguring wounds that will be noticed by people in medical training, and dealt with accordingly.  Last night I went to a moulage class put on for our local CERT team, and it was really a lot of fun, in a gross, messy kind of way.  I hope to have pictures later. 

We spent over an hour looking at a combination of moulaged volunteers and actual accident victims to get a feel for what we were trying to achieve.  Yuck.  People can get hurt in really messy ways.  Then we set about making each other look gross, which was much more fun. :-)

My favorite ones were the burns.  It turns out to be really easy to make some really nasty and convincing looking third degree burns (using common household items).  I had a harder time with the "impaled objects" and compound fractures.  Mostly because I was trying to work on myself.  It's way easier to get a chicken bone to stick out of someone else's arm than your own.  And it takes a lot more artistic skill than the burns to get the colors right.  Ah, well.  Now I have an excuse to dress my kids up as accident victims for Halloween.  I need to practice.

Wednesday, 27 October 2004 15:16:34 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 26 October 2004

As most of you probably have already heard, according to Dare, we won't be getting XQuery with Whidbey. 

LAME!

One of the reasons given for this decision is that customers want something that is compliant with W3 standards.  OK, that's true.  I would disagree that people will only use something that is compliant with a full recommendation.  Back in the day when MS first started putting out XML tools (early MSXML, SOAP Toolkit, etc.) many of those tools were built around working drafts, and we still managed to use them to get real work done.  I would argue that even if the XQuery spec were to change substantively between now and it's full recommendation-hood (which I doubt) there's plenty of opportunity to get real work done with XQuery starting right now. 

The counter argument is that people don't want to make changes to their code when the real spec ships.  Guess what!  There have been breaking changes introduced in each new revision of the .NET framework.  People have to change their code all the time.  I had to unwind a huge number of problems do to the changes in remoting security between .NET 1.0 and 1.1.  Somehow we manage.  The excuse of "well, you still have XSLT" just doesn't cut it IMHO.  XSLT is a much more difficult programming model than XQuery, and most people to this day don't get how the declarative model in XSLT is supposed to work.  XPath 1.0 is very limiting, which is why there's an XPath 2/XSLT 2 (which also are not going to be supported in Whidbey!). 

I have to wonder if performance issues aren't closer to the truth of why it's not shipping.  Writing an engine that can do arbitrary XQuery against arbitrary documents certainly isn't an easy thing to do.  Think SQL.  SQL Server is a non-trivial implementation, and there's a reason for it.  I'm guessing that the reality of trying to make XQuery perform the way people would expect is a pretty daunting task. 

Either way, I think it's a drag that we won't get XQuery support, recommendation or no.

XML
Tuesday, 26 October 2004 11:00:54 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

Steve Maine is in the midst of the perennial debate between SOAP and REST, and I feel compelled to add my two cents...

At the XML DevCon last week I noticed that it continues to be fashionable to bash the existing Web Services standards as being too complex and unwieldy (which in several notable cases is true, but it's what we have to work with at this point) but that doesn't change the fact that they solve real problems.  I've always had a sneaking suspicion that people heavily into REST as a concept favored it mostly out of laziness, since it is undeniably a much simpler model than the SOAP/WS-* stack.  On the other hand, it fails to solve a bunch of real problems that SOAP/WS-* does.  WS-Addressing is a good example. 

I spent two years developing an application that involved hardware devices attached to large power transformers and industrial battery systems that needed to communicate back to a central data collection system.  We used SOAP to solve that particular problem, since it was easy to get the data where it needed to go, and we could use WS-Security to provide a high level of data encryption to our customers.  (Utility companies like that.)  However, we had one customer who would only allow us to get data from the monitors on their transformers through a store-and-forward mechanism, whereby the monitors would dump their data to a server inside their firewall, and we could pick up the data via FTP.  This is a great place for WS-Addressing, since all the addressing information staid inside the SOAP document, and it didn't matter if we stored it out to disk for a bit.  There is no way that REST could have solved this particular problem.  Or, at least, no way without coming up with some truly bizarre architecture that would never be anything but gross.

REST is great for solving very simple application scenarios, but that doesn't make it a replacement for SOAP.  I agree that many of the WS-* standards are getting a bit out of hand, but I also agree with Don Box's assessment (in his "WS-Why?" talk last week) that given the constraints, WS-Addressing and WS-Security are the simplest solutions that solve the problem.  There's a reason why these are non-trivial specs.  They solve non-trivial problems.

So rather than focusing on REST vs. SOAP, it's more interesting and appropriate to look at the application scenarios and talk about which is the simplest solution that addresses all the requirements.  I don't think they need to be mutually exclusive.

Tuesday, 26 October 2004 10:01:27 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Friday, 22 October 2004

Update:  the link to the article seems to be broken.  Fie!

The Marin Independent Journal published an article about some of the fascinating medical work my Dad and his wife do in San Francisco.  Pretty cool stuff.  The article mentions the trip we took to Disneyland this summer.  Once again, the Internet knows everything. :-)

Friday, 22 October 2004 12:29:07 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Thursday, 21 October 2004
Wow, Rory drew my head.  I've arrived. :-)
Work | XML
Thursday, 21 October 2004 09:35:02 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 20 October 2004

Sam Ruby is talking about problems with textual data out on the web, or more specifically in the context of RSS, having to do with bad assumptions about character encoding.  As someone who once did a lot of work in localization, it's a subject near and dear to my heart. 

I'm always amazed that still to this day people don't get that there are such a thing as character encoding. 

Sam points out that an upper case A and the Greek Alpha show up in most fonts as the same glyph.  However, they are different code points in Unicode. 

He's moving this idea up the stack to show why there are so many conflicts between HTML/XML/RSS/etc.  The rules for character encoding are different in all those systems and are enforced differently by different tools, which is what causes so many RSS feeds to be badly formed. 

He started the presentation talking about how XML is an "attractive nuisance" with regard to the encoding issue, in that it leads people down the primrose path to thinking all their encoding issues are solved just because XML is supposed to take care of encoding. 

All in all, the issues Sam is talking about are pretty obscure, and appeal mostly to XML wonks, but that doesn't make them any less valid.  The reality is we've all learned to deal with it most of the time, just like we're used to IE fixing up our bad HTML tables.

XML
Wednesday, 20 October 2004 15:51:23 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 18 October 2004

Just two more days until the Dev Con.  I had a great time both speaking at and attending last year, so I'm looking forward to another exciting time.  Scott and I will be talking about some of the things we're doing at work around XML Schema and using "contract first" coding in a non-Web Services context. 

I hear there are still a few more open seats...

XML
Monday, 18 October 2004 18:21:17 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

Being a non-CS degree holder (I can tell you all about Chinese vs. Japanese Buddhism though) I've always been a bit intimidated by the idea of parser/compiler building.  Luckily, there's Coco/R.  I'm intimidated no longer!  I've been playing around with creating a custom scripting language for some of the code generation we're doing, and this turned out to be a really easy way to parse/compile the scripts.  Coco/R is distributed under the GPL, and source is available.  There are versions for both C# and Java. 

I was really impressed at how easy it was.  Basically you write an EBNF definition of your files to be parsed, and then annotate them with native (C# or Java) code that does the compilation.  Here's an example from the sample that comes with the distribution...

/*------------------------------------------------------------------------*/
MulOp<out int op>
=                        (. op = -1; .)
  ( '*'                  (. op = times; .)
  | '/'                  (. op = slash; .)
  ).
/*------------------------------------------------------------------------*/
RelOp<out int op>
=                        (. op = -1; .)
  ( '='                  (. op = equ; .)
  | '<'                  (. op = lss; .)
  | '>'                  (. op = gtr; .)
  ).

The EBNF stuff is on the left, and the native code on the right.  Super easy, and the parsers work great.  Very fast.  They are also very easy to debug, as the generated code is very well laid out.  It corresponds to the EBNF constructions, so debugging the process is very easy.

If you ever find yourself needing to do some parsing, check it out.

Monday, 18 October 2004 11:32:36 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 08 October 2004

Turns out that if you have multiple versions of the same assembly, say 1.0.0.1 and 1.0.0.2 in your probing path, only one of them will ever get loaded.  Here's the deal...

I've got an app in

c:\myapp

in it are myassembly.dll v1.0.0.1 and myapp.exe.

There's a subdirectory

c:\myapp\new

that contains myassembly.dll v1.0.0.2, plus a new assembly newassembly.dll, which is dependent on v1.0.0.2 of myassembly.dll

In myapp.exe.config, I've included the "new" subdirectory in the applications private path, meaning that it will look there for assemblies when doing assembly binding.

 <runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
   <probing privatePath="new;"/>
  </assemblyBinding>
 </runtime>

When the application loads newassembly.dll, I would have thought that it would correctly load the 1.0.0.2 version of myassembly.dll, and that the application would load the 1.0.0.1 version to which it was bound.  Alas, that turns out not to be the case.  Fusion comes back with

LOG: Post-policy reference: myassembly, Version=1.0.0.2, Culture=neutral, PublicKeyToken=xxxyyyzzz
LOG: Cache Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/myapp/myassembly.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\myapp\myassembly.DLL
LOG: Entering run-from-source setup phase.
WRN: Comparing the assembly name resulted in the mismatch: Build Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

We had assumed that fusion would skip the wrong version and keep probing for the right one.  It looks like it just finds the wrong one and bails.  Of course, if we put both versions in the GAC, it works just like we would expect, which makes sense, that being what the GAC is for and everything. :-)

Friday, 08 October 2004 14:20:04 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 05 October 2004

I may just have a new favorite XML editor.  I caught wind of Stylus Studio 6 [via Mike Gunderloy] so I downloaded a trial copy and checked it out.  Wow.  I'm pretty impressed.  It's the same price as XMLSpy Pro, but includes support for XPath (v1 and v2), XQuery, Web Services testing, and a pretty good schema-to-schema mapping tool that creates XSLT files.  Plus it has a schema editor which looks pretty good, lots of data conversion tools, support for custom extensions (if you have your own file types), etc.  Lots of good stuff here.

What is even cooler is that they have a "Home" version for non-commercial use that has almost all of the features of the pro version (unlike the pretty well crippled XMLSpy Home) for only $50.  I'll definitely turn my students on to this next week.  That's a lot of functionality for very little money.  The schema editor in the Home version isn't quite as cool, and there are a few other features it doesn't support, like web services testing, but it looks otherwise pretty highly functional. 

If you don't care about the WSDL editor, there might be a lot to recommend in the Pro version over XMLSpy Enterprise, at about 1/3 of the price.

XML
Tuesday, 05 October 2004 13:27:23 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  |