I want RelaxNG!

RELAX NG is a worse choice for most developers. Most developers see XML Web Services as a way to push around objects or relational data wrapped in angle brackets. They simply need a way to describe a Type Annotated Infoset. Something like the now obolete XDR language that Microsoft was pushing a few years ago. This corresponds to a subset of XSD or RELAX NG. The added features that make RELAX NG preferable to XSD are in the area of document validation which almost all developers of XML Web Services do not do anyway.

I know I said it before. But I can't help but think this is a tooling issue. I think most developers see XML webservices as a remote object calling mechanism (as Dare mentions) because they are working at the wrong level. To me, Mark's point about seeing the future with c# and java as the 'low level' programming is spot on. But because we're nowhere near that point devs are using high level language constructs directly to do *everything*. I think what many people are doing today is putting a toe in the water. Yes it's easy to create web service enabled apps with asmx but today it does it in a way that encourages bad practice for enterprise-scale services. I've been implementing web services as part of a large framework over the last couple of years. I've really been trying to ignore XSD because I can't see clearly what problems it's solving for me so it's best to avoid it (maybe that's why the WS-* specs have been trying to as well?). So, like, why do I need it at all? What doesn't help is everyone saying that it's pretty bad at the problems it's trying to solve (mainly object binding) with no clear workable alternative. What I've found though of course is that you DO need something. This is because a webservice framework is basically a modern day hub eg WSAD-IE, BizTalk etc. What happens here is that you MUST validate the messages before processing them. Even if you can figure out what service (orchestration, asmx, whatever) a bad message is destined for and you process it, weird things are likely to happen. So you need the validation to prevent the "Type Mismatch" if you will because it can be really hard to figure out what went wrong during the processing. With validation, it's really obvious what the root cause is. So it’s interesting that all the webservices hub vendors are basing themselves on XML schema when it can lead to such horrible ambiguity. I think if we carry on down the same road devs will inevitably find themselves connecting their webservices together to compose larger tasks (and why not) but will inadvertently hit these problems and either a) notice - and not know what to do about it or b) not notice, and create brittle systems. This way of viewing webservices can only make sense if we stop thinking about mapping objects to XML in our *own* code using XSD and see the actual services we are creating as document-oriented. But this then causes us to map the XML to objects in our environment ourselves because XSD can’t. So much for advanced tooling.

I was hoping (like everyone else) that XSD would be my saviour. And it isn't. I have also been looking at Relax NG and some of its ideas are compelling. But I'm nowhere near making my mind up - and I still feel as a developer that why do I have to? Why is this decision mine? Like on the MS platform we had DCOM. I didn't have to decide which remoting mechanism to use from my MS toolkit (VB, ASP, VC++ etc). I know you *can* use others, but the decision to use COM is the OBVIOUS one in an all-MS environment. Unfortunately it appears that XSD is the obvious one (mainly due to ubiquitous support) but it’s also the *wrong* one. I think if you give developers such a free choice in this level of the stack we're in for a nightmare. As developers we're good at choosing the best language to implement a solution and consequently how to solve the problem in that language. Again that's why I agree with Mark's point that all the other stuff just won't be expressed in c#/java in the future. The tooling just has to come to the rescue with pre-configured guidance to help me while I've still got some toes left :-). So Tim, I’ve gotta ask, do you really believe that Relax NG is the right answer? None of us want the pain of moving from one wrong answer to another. Like you say they’ll never be fewer webservices than there are today.

One point I forgot to make is that why do we all have to agree which schema language to use? You seem to be suggesting RELAX NG because XSD can't express our intentions in all cases. So we ALL have to stop using it in order to interop otherwise I'll send you a message you just can't validate. But this is a nonsense because how do you enforce that? And because I can equally define message formats that can be validated in XSD that aren't possible in RELAX NG. Or at best if we can, we just tie each other up in knots of unbelievable complexity trying to. Arghhhh! What do we do?

Hi Tim,
Why isn't anyone talking about a "Command" oriented service messaging systems? Instead of sending "Data" over the wire, send Commands that create the "Data" over the wire at the other end. I know, your saying what's the difference.. the difference is subtle but quite profound. Especially in terms of validation and version.

Jon,
I agree with your sediments. Schema is simply a validation tool, that is all it should be. It is a Go-NoGo gage for the actual truth, which is the actual data on the wire.

Ok, given. Relax NG is better than XML Schema. But, anybody who's used both knows that they are version similar and that Relax NG has a few constructs that make it more flexible than XML Schema. Now the tricky part. We replace XML Schema w/ Relax NG. Tomorrow, somebody says Schematron is even better. Then what?

By that logic, should we not move from SOAP over HTTP to SOAP over TCP because SOAP over UDP might turn out to be better still?

I get the point: we don't want continuing churn. But we do want improvement.

Tim-

Mark Nottingham writes about the problems with XML Schema, and makes a case for development of a new data model with a mapping to the XML infoset. There's an interesting follow-up from Tim Ewald, and a follow-up on that one from Dare Obasanjo. Dare argues that XSD is preferable over RELAX NG for the most usual use case -- the...

High level tooling requires a standard message definition language. Additional validation could use everybodies favorite.

Curious - what do you guys think of CAM?

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cam