Archive for August, 2007|Monthly archive page

Streaming Violations

In general on August 15, 2007 at 7:41 pm

Streaming Transformations is a part of the family of validation standards being created as Document Schema Definition Languages (DSDL) through ISO. DSDL is, of course, the great hope of the publishing industry for providing more appropriate technologies for arbitrarily-structured documents, as opposed to the legacy data-based technologies currently popular with XML developers. STX, a one-pass transformation language for XML documents, has been proposed as the seed technology for the streaming transformation section of DSDL. As a good starting point for constructing a grammar-based technology, STX proffers a candidate technology that would allow ISO to make progress in a reasonable timeframe.

Apathy ruled the voting to consider whether STX should form the basis for part 6 of DSDL. Only five countries bothered to cast a vote. This is somewhat understandable given the enormous energies being consumed by the colossus that is the OOXML fast track consideration. The Canadian and Japanese national bodies returned no votes on the issue of whether to adopt STX as the foundation for DSDL part 6. This will delay any progress of creating a standardised streaming technology through ISO. The record of voting is publicly available on the brilliant JTC1SC34 site – where we can see the rationale behind the voting.

Considering the problems users have with extremely large XML files, and the urgent need for better tools support, the voting is intriguing. STX may not be perfect, but adopting it as a starting point would have moved the DSDL process forward considerably and allowed further work using STX as a basis. The rationale given by Japan is reasonable. But the reasoning from Canada does not appear to be so straightforward. So why did Canada vote no? Well the answer may lie in a conflict of interest that has now been exposed. It appears that the W3C XSL WG is considering streaming requirements for a future version of XSLT. However, if this knowledge was not public at the time of the ballot – how could Canada have acted in the interests of another standards body?


Design and APIs

In general on August 1, 2007 at 8:10 pm

One of the skills a good engineer is expected to exhibit is design. This may come as a surprize to some but a good engineering solution will exhibit many principles of desisgn expertise that come from experience and the application of the art in which the enginner practices. This is as true for building audio filters for electronic circuits and bridges as it is for Application Programmer Interfaces.

So what is good design? Good design is what makes things invisible. Things that are well designed become more elegant, usable and useful that items that are not. This has a direct commercial impact on businesses – in manufacturing design is obviously a factor that affects the desirability of one product over another. But the commercial imperative of design is much deeper that aesthetics. Design affects adoption, design affects maintenance, design affects visibility.

An API can be one of a company’s greatest assets. The decision to code to your interface establishes a greater mindshare in the people you work with than merely being another name in a list of suppliers. Done well an API helps integrate your services into someone else’s business processes. However, bad design should not get off the developers to do list. Exposing your understanding of your value proposition to customers is a daunting step and one that can fail much more easily than many realise.

Of course the best APIs are released once they are already proven within their organization. Since APIs cannot radically change, there needs to be a high level of confidence that the decisions taken will stand up to use over a lengthy period of time. Design should make things easy whilst being useful. Rather than reiterate whats already known, I refer you, dear reader to an existing exposition of the value of APIs.

The important things about public APIs is that they will not necessarily be used by programmers! Programmers are people who spend all their time writing code. Is one of those people really interested in your business processes? Isn’t it much more likely that the real audience for your API is the technically-leaning component of your customer base? So write with those people in mind – and they can explain what needs to be done to their programmers. Remember programmers write sort algorithms – not business requirements.

Of course, once an API is released in the wild, there is an implied contract to keep servicing it. Unless there are exceptional circumstances (like an acquisition involving a different business strategy, and even then there is a loss of goodwill) users are not going to be happy if their interface is whipped from under their feet. Caveat emptor – or make sure you know what your backup plan is and ensure you are loosely-coupled to your services of choice.