After reading this on Gordon's blog, it got me thinking about RELAX NG again.  I had been following it pretty closely before XML Schema achieved the W3C seal of approval.  I really liked it.  It is extremely easy to read.  It is easy to understand.  All the things that James Clarke mentions.  But it isn't even on my radar anymore.  Why?  Two main reasons.  The first is that my customers have never heard of it.  They've heard of XML Schema.  The second is that neither Microsoft nor Sun support it.  Is that heavy handed of me?  Yep.  Sure is.  But the fact of the matter is the people I deal with are mostly Microsoft developers, and they want to deal with specs that Microsoft says are good to use (whether they are or not).

I read today that Sun has something that will validate RNG.  MHV?  Can't recall now.  And Greg can attest to my penchant for inflicting obscure solutions on the development team :-)  But the point's taken.  XML Schema has the mindshare, and the fact is, a lot of us, myself included, have been clamoring for Schema for years.  Gotta be more careful what I ask for next time :-)

Of course with that said, I had to dig up my code that actually implements RELAX NG :-)  Never finished it, and not even sure I should have it on my system (code written for a company that is now out of business).  But it would be a good exercise to finish it up and maybe do an implementation in .NET.  Maybe that will help the adoption process :-)  Of course, don't hold me to that.

If you are interested in playing with RELAX NG in .NET, check this out.  I haven't looked at it closely, so I don't know how much it implements.

Thanks for the link, it's on my queue.  What language is your implementation in? 

Some more followup to my reading from tonight.  Simon St. Laurent has a blog entry that he wrote in response to the brouhaha on xml-dev.

Then there's Len Bullard, on xml-dev:

Nodes is nodes.  Properties is properties.  Tell me who gets to name the names so we can get on with business.

That's it. 250 emails later, plus a bunch of other pages, I'm going to bed.

Just for the sake of experimenting, I decided to try the original idea.  Guess what?  It doesn't work.  Why?  Because System.Xml.XmlValidatingReader throws an exception if the System.Xml.XmlReader you pass in to the constructor is not System.Xml.XmlTextReader.  Of course, the documentation does specify that it will throw an exception so it is my own fault for trying something that was destined to fail.  Just seems kind of lame to me.  [Justin Rudd's Radio Weblog]

Now that restriction sounds familiar, I remember being burned by this a few months ago.  The System.Xml classes seem to be that way: they entice you to do something that doesn't work.  I guess we can hold forth hope that the v.next of the FCL will allow other XmlReader types to be used here, why else would they declare the constructor that way?

My own experiments were a little disappointing too, though in retrospect I was expecting too much.  What I thought I could do was to validate a document part way, attach a schema, then validate the rest.  But this really doesn't make sense; considering that there's no namespaces, by introducing a schema that wasn't namespaced, you'd have to completely reparse the document to make sure it was valid.  How would this work with namespaces?  I suppose that the XmlResolver would get a call at the point a new namespace was introduced, which would cause the schema to be loaded.  Would the reparse restriction still apply?  I bet it would.  All this seems to be discouraging validation on documents, which might be good practice in general on a production environment, but still might be desirable.  Schema validation is already expensive and it seems like this makes it more so. 

Justin, are you going to publish your RSS schemas?  One other experiment I was considering is whether it would be possible to combine your schemas into 1, using the fixed attribute on the version attribute's declaration to determine which way to validate.  This could be another wild goose chase, but offhand, could you construct something like this? 

<xs:schema elementFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name=RSS type="rssType"/>
  <xs:complexType name="rssType" abstract="true"/>
  <xs:complexType name="rss091Type" >
      <xs:complexContent>
        <xs:extension base="rssType">
          <xs:attribute name="version" fixed="0.91"/>
        </xs:extension>
      </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="rss092Type">
    <xs:complexContent>
      <xs:extension base="rssType">
        <xs:attribute name="version" fixed="0.92"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
</xs:schema>

It seems like it would work, but I get the feeling that I'm just moving the hack from the code to the schema.

Clay Shirkey: HTTP and HTML are the Whoopee Cushion and Joy Buzzer of Internet protocols.  Guido Casper: It's certainly worth a read for anyone involved in the SOAP vs. REST debate.  Thanks Guido! [Sam Ruby] [Sam Gentile's Radio Weblog]

This is pretty interesting and reinforces my earlier argument that Paul Prescod was really using some weak arguments when he was trying to fit REST into the ISO model.  The Internet and later the web have been historically at odds with more scholarly efforts.  Somewhere, I saw that this article is about 4 years old. 

It's interesting to watch the debates in the XML and Web Services communities; on the one hand there's the Schema vs. RELAX-NG (vs. the DTD crowd that's still hanging on) on xml-dev, where there seems to be serious rebellion against Schema among people like Simon St. Laurent, E.R. Harold, and Tim Bray, mostly objecting to its complexity.  This same group opposes SOAP on mostly the same grounds, but I don't consider them REST proponents, they're just non-adopters of SOAP.  On the other hand, there's REST vs. SOAP, which is interesting in that the REST proponents are using arguments of architectural purity, while the SOAP side's stronger argument is the number of working implementations of SOAP web services, yet REST is trying to claim that ground by saying that they've had working implementations for years.  Each of these battles has the sides well dug in, though the resistance from the non-adopters seems to be stronger than the push from the early adopters.

I have a ton of catching up to do.  I've been busy building servers and working through deployment issues, and I have 250 unread emails that I want to get through tonight.  Someone started a topic on rest-discuss about a RESTful travel agent implementation, it's always entertaining, and sometimes enlightening, to hear outside ideas about how the travel industry works, or should work.

Just got an email regarding a couple .NET bugs that I thought I'd pass along:

1. If you have an ASP.NET web application that calls into web services on another machine, the default TCP connection limit between the two web servers is two sockets. This is really bad if you've got many browser clients hitting an ASP.NET app because all of the web service requests the ASP.NET app makes are sent through just two socket connections. If you're running this configuration you will probably need to increase the connection limit. You can add a config setting in the <System.Net><connectionManagement> section of the web.config or machine.config. Bumping it up to 15 was suggested for a 2-proc web server, but this setting represents the upper limit so the machine won't open more connections than it needs if you do set it higher than that. The reason two connections is the default is actually because the HTTP 1.1 spec states 2 connections should be the max between client and server, and the ASP.NET app is treated as a single client to the web service host regardless of how many browser clients it is handling.
2. There is a bug in the autogenerated proxy class when you add web references in VS.NET, where the Timeout value is ignored or not fully recognized. So for example if you set the webservice.Timeout = Timeout.Infinite, it may still time out after the default timespan of 100 seconds. You have to add some code to the autogenerated class to correctly propagate the Timeout value down to the web request object. This is a known issue.

This problem could cause one or both of the following exceptions: System.Net.WebException: The operation has timed-out.

System.Net.WebException: The underlying connection was closed: The request was canceled.

A message from Tim Bray on xml-dev pointed me to a message from James Clark on another mailing list, blasting XML-Schema and specifically, its promotion by the IETF as the schema language of choice for IETF specs. James favors RELAX-NG (clearly there's a conflict of interest here), but I think that the points he brings out about XML-Schema are interesting. (Dare Obasanjo offered a refutation of point #7, and my experience is that James' observation isn't valid). I have passing interest in alternatives to XML-Schema, but it's one of those things that never gets enough priority for me to really do anything real with.