YODEL FAQ
Please send me any questions, comments or criticisms you might have.
Is the YODEL Specification Open Source? How about the implementations?
or: "blah...blah...M$ sucks!...blah...blah...penguins!...Windoze...blah...blah...blah...monopoly...blah."
The YODEL specification is Open Source (as much as a specification can be). See the published Code Policy for all Depressed Press materials. This policy is non-viral and very liberal. All Depressed Press implementations are Open Sourced under the same policy.
While the Depressed Press encourages other authors to Open Source their implementations as well it can't (and wouldn't) enforce such a suggestion. Make sure to review any implementation to ensure that the licensing requirements suit your needs.
I'd like to create a YODEL implementation. Any hints?
or: "...blah...ME BUILD!...blah."
Great! I want to see YODELing across all platforms. I'd love to see your wristwatch YODELing to your toaster!
To start review the Specification. It has both the simplified XML specification and rules for serializers and deserializers. Just follow those rules and you should be set. Looking at some of the other implementations may also be useful (for example the JavaScript implementation can easily inform a Java or ActionScript implementation.
Once you're done please send us a link!
YODEL Sucks! Why not just use [insert favorite alternative]?
or: "...blah...SOAP...blah...more mature...blah...blah...XML-RPC...blah...better support...blah...blah...JSON...blah...blah..."
If you already have a favorite option that's working for you then I don't see why you'd want to use YODEL. You shouldn't replace a tool you're happy with for another that does the same thing (I think there's a lesson about life in there someplace). I believe that YODEL offers some benefits over other solutions in many circumstances but may not in many others. I encourage you to review other options and make your own choice.
For the sake of explanation here are some of the more common options and how, In my opinion, YODEL stacks up. All of these options solve the same essential problem that YODEL does and all are open source.
SOAP is a widely supported standard for RPC (remote procedure calls). It's also, by a very wide margin, the most complex solution here. SOAP provides so much freedom in its data formats that most implementations can not easily communicate with each other (translations are required). SOAP is designed to accomplish more than simple data transfer which adds to its already daunting complexity. While its support on the server-side is strong it's support on the client-side (JavaScript, ActionScript, etc) is relatively weak.
This is a clever solution leveraging native JavaScript notation which has broad (and active) language support. JSON is limited to only those data structures that can be described using JavaScript's literal notation (for example array-based hash tables can't be described). JSON cannot differentiate between some data types (strings and dates for example) and cannot be extended with new data types. It is the only solution presented here that is not an XML dialect. Because of this JSON is the most compact solution by far but lacks the intrinsic validation options of XML.
WDDX is a venerable solution which was accepted with some enthusiam by the ColdFusion community (where it orginated) but failed to gain much acceptance with the broader Web application development community. Although the SDK offers broad language supprt the components provided are bordering on ancient. WDDX is a fairly verbose dialect, but not as verbose as some. WDDX can't be properly validated using an XML Schema Definition.
The oldest solution here XML-RPC continues to enjoy broad and active support, there are implementations for nearly any language or platform that you might want to name. Like SOAP XML-RPC defines methods for invoking remote procedure calls although, unlike SOAP, this does not add markedly to its complexity. The standard is, by far, the most verbose of those here with XML-RPC data packets often twice the size of others. The official XML-RPC specification is rather vague on many points (date format and the handling of nulls being two examples).
YODEL attempts to address some of my complaints and concerns with these other options. Unlike SOAP and XML-RPC YODEL is a data-only definition. Unlike WDDX and XML-RPC it supports mechanisms to greatly reduce the size of the packets required to pass data. Unlike JSON it supports distinct data types like dates and binary data and can be extended to support others. YODEL can be described using XML Schema Definition and is designed to be easy to parse and generate.
