Interface design (in XML)

MARKOV Solutions provides various services, such as Perl and C programming (like XML and email processing). Although experienced in many fields, we do have a few outstanding specialities, one of which is on the subject of XML interface design.

"XML" is a way of drawing lines on a sheet of paper: some say XML is synonymous for an "Open Standard", but in reality it is nothing more than a clean way to denote information. The data to be written on these `lines' still need to be described and published to make into an "Open" standard.

Quite a number of alternative syntaxes for XML do exist, like YAML and JSON, but companies nearly always elect XML because other companies picked XML before them. The strongest advantage of XML certainly isn't the XML syntax itself, but are the (commercial) standards which have been developed around it. Popular standards are, for example, XML schemas, WSDL, UDDI, SOAP, and XMPP.

XML-Schemas and WSDL

XML schemas formalize the structure and content of XML message in detail. It's an extremely powerful descriptive language, but at the same time too "inventive": the XML schema specification is exceptionally unreadible and complex. On the other hand, it is one of the few interface description mechanisms available and certainly the most well known.

Where the XML schemas are being used to describe the structure of the messages, the WSDL wraps that knowledge with facts about internet services, usually servers using SOAP.

Do it yourself, or hire a specialist?

Schemas and WSDLs are produced to exchange data with other people, or to collect data yourself to store for a longer time. The specifications need to survive much longer than the single applications, because changes on multiple systems really hurt. Therefore, you must take the interface development very seriously at the earliest stage of a new project.

Are you capable of designing your own schema, or will you hire a specialist for a few days? Try answer these questions, to test your schema knowledge. Move over "answer" to get a pop-up which explains the answer.

1. Can you explain the difference between nillable="true" and minOccurs="0"? Answer

Nillable is an explicit "still missing", where minOccurs reflects an implicit "we do not have it".

Example: when an address is "nillable", than we express that the data should have been available but (still) is not. When the address field is options, than we can leave it out without consequences.

Many, mainly older, schemas use nillable where they shouldn't. Sometimes, it get used to express which message features are available. But isn't documentation the preferred spot for the? Most people do not read XML for pleasure.

 
2. When to use xsi:type and when substitionGroup? Answer

The substitutionGroup mechanism is a recent development: just over eight years old... and most people never read a book which since. The xsi:type mechanism is much older and for that reason still used... alas.

According to the schema specification, any element in a message may have its type changed to one which extends that type via an xsi:type attribute. Imagin the power of an anyType! The schema does not describe where these attributes may be found, so this misfeature frustrates the main purpose of the use of schemas: descriptiveness.

Elements of a substitionGroup can replace the element which is explicitly referred to. Not the type of the element is magically replaced, but the whole element has a different name. Clear, uniform and maintainable.

 
3. The difference between dateTime and date? Answer

The simple answer seems to be that dateTime adds hours, minutes, seconds. But that's just too simple. The date refers to a day: a timespan of 24 hours, where dateTime flags a single moment in time.

When relationships like duration or expiration are involved, it is crucial to pick dateTime, even when the exact moment in the day is not known.

 
4. What is the data type of elements and attributes where this is (accidentally) not explicitly specified? Answer

When there is no type specified, then the default will be used. For elements, that is anyType, an simple data-element or a complex nested thing. In short, totally unclear and everything is accepted.

An attributes has as default anySimpleType, which provides a little more clarity. But, for instance, what do blanks mean in such attribute?

 

All answers correctly answered? Then we can not add anything to the development process of your interface.

Offer

Dozens of (usually quite expensive) applications help you click together a schema or WSDL in no time. But that is not the complexity of interface design. The difficulty lays in the design of a message structure which can last and optimally defines the data exchanged or stored.

To be able to design a good interface, you need to involve its developer as early as possible in the project. Only in the very early phases of the developement process, there still is a chance to bend the data structures in the right way.

We have a few negative experiences with schema evaluation at-the-end. In that phase, companies are very offensive against the required improvements in the schema once the test-phase is entered. Those schemas get published full of avoidable mistakes. Don't let that happen to you!

Get us in on the first day of the development of your XML application. With just a few days of support, we will avoid year worth of complications.

2011-10-10