# 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]  | 
# Tuesday, 14 September 2004
I've got six three, if anyone wants one.
Tuesday, 14 September 2004 11:52:53 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  |