Partager via

RELAX NG, XSD and XML Web Services

  • Article

In his post I Want RELAX NG! Tim Ewald writes

This recent post on Mark Nottingham's site pushed me over the edge. I agree with Sean's comment: I want Relax NG. Can I make systems work with XSD? Yes, sort of. But it adds a ludicrous amount of complexity. First you have to know how it works, then what not to do because it's too complicated (like complicated type or element substitution models), then figure out how to contort your schema to do what you want (like extensibility and versioning). Relax NG is much simpler and much closer to how XML actually works. And yes, you can still map it to /from objects if you want to.

I can't help but wonder why, if WS-* and SOAP 1.2 keep XSD at arms length (referencing simple types only and providing non-normative schema definitions) and WSDL 2.0 defines its own simple types, everyone assumes I want to use XSD to define my Web service interface. Pretty much everyone I know who works in this space agrees that Relax NG is a better choice. What is stopping us from making this change?

This is one of those times where I both agree and disagree with Tim. To explain why, I first need to list the two three reasons people tend to write schemas.

  1. To provide a way to annotate an XML document with type information and thus created a type annotated infoset.
  2. To provide a means to ensure that an XML documents satisfies the constraints of a given message contract
  3. To provide terse, human readable documentation of an XML format.

In most developer scenarios [including XML Web Services] the most popular use case is the first from the list above. An XML Schema is used primarily for mapping the contents of an XML document either into relational tables (e.g. SQLXML, ADO.NET DataSet) or into a set of programming language objects (e.g. System.Xml.Serialization.XmlSerializer). Every XML Web Service toolkit I have encountered emphasizes this scenario and in fact most customers do not use XML schemas for validation of business documents for either performance reasons or the fact that their business rules cannot be adequately described using an XML schema. The main problem with XSD for this use case is that it is actually too expressive and has a richer type system than either the relational model or traditional object oriented programming languages. This leads to impedance mismatches which makes it hard for XML Web Service stacks to map schema declarations to objects thus leading to calls from folks like the WS-I to propose creating a subset or profile of XSD.

On the other hand, XSD is notoriously bad at dealing with the second use case described above. The language makes either makes it hard to describe common XML idioms (see the hoops I have to jump through in my Designing Extensible, Versionable XML Formats article) or impossible (e.g. if an attribute has a certain value then the element should have a certain content model or the providing a choice of attributes). This is where RELAX NG shines. Of course, being more expressive than XSD means that the impedance mismatch between it and the relational and OO models is even more significant. 

In practice today, most XML Web Services need an XML schema language for creating type annotated infosets not for validating message structure. This means that for their use cases XSD is preferable to RELAX NG. Ideally, a simple language that just allowed creating named structures and primitive types such as Microsoft's now-obsolete XML Data Reduced (XDR) would be even more optimal.  

Of course, the XML Web Services world could one day evolve to the point where being able to validate incoming messages against a schema is deemed more important than being able to deserialize the XML into objects and vice versa. In which case, Aaron Skonnard's statement in his post Could RelaxNG Replace XSD? which describe the existing industry inertia around XSD is also a point to consider.

Comments

  • Anonymous
    August 19, 2004
    The problem with your analysis is that we should be discouraging 1 and encouraging 2. Moving to RelaxNG would be a clear signal to developers of that guidance.
  • Anonymous
    August 22, 2004
    I'm new to this area. This discussion in particular interests me, as I am looking into methods of describing useable services.

    Some of what you are saying, if I understand it at all well enough, seems to be covered by WS-Choreography. Even more so, it would seem that the issue of "a message contract" fits right into the domain of what some see as the need for tools to define service semantics.

    Ok, your post is refering to documents, not services, but isn't the requirement to go heyond "typed annotated infosets" (which seems to me to be synonomous with "syntax") an issue of defining semantics? And, if so, wouldn't the "complexity" of XSD that you refer to actually be an issue of "ambiguity" that arises due to the flexibility of XSD?

    To use an anology, the English dictionary is huge, and complex, and communications in English would be impossible with no semantic context?
  • Anonymous
    August 22, 2004
    The comment has been removed
  • Anonymous
    August 25, 2004
    It is true that the use of RELAX NG schemas for providing types is not
    widely implemented. Meanwhile, W3C XML Schema schemas are very painful to
    write. Therefore, an obvious improvement is to use RELAX NG as a
    front end to W3C XML Schema. Trang by James already converts RELAX NG
    to W3C XML Schema. If such conversion tool is provided by Microsoft,
    more users are happy to use XML Web Services and the investment to W3C
    XML Schema will continue to be useful.

    It is certainly possible to choose a subset of RELAX NG and implement
    more software tools for using schemas as types.
    But I am still skeptical about the use of schemas for
    providing types. One reason is that data binding tools generate
    incompatible programs when schemas evolve (user programs have to be
    rewritten). I am wondering if SQLXML, ADO.NET DataSet,
    System.Xml.Serialization.XmlSerializer has similar problems.
  • Anonymous
    August 26, 2004
    I guess I was alluding to the possibility that the complexity of the XSD specifications that people may be writing were the result of trying to capture more then the syntax (format and structure) of an exchange. That they were attempting to constrian the semantics (sequence and conditions) of the exchange by over specifying the syntax with XSD (like this hasn't happened so many times before).

    I didn't mention flexibility. Flexibility is not the same as complexity, even though flexible solutions often turn out to be complex.

    I can believe that there would be many current real world scenarios where format and structure should be sufficient. This is not to say that there are some who are "pushing the technology", perhaps into places it's not ready to go.

    I'm interested in these "typical XML Web Service scenarios" that you mention. Without revealing customer information, could you describe what these scenarios are?