Warning: This post is a wordy and contains some pretty heavy-handed criticisms about DDI and its implementations – so I’ll reiterate that this is my personal opinion as an open-source developer working with DDI-Lifecycle.

So in two recent posts, I presented 2 alternative approaches(2) to extending the DDI information model – one method using XML Substitution Groups, the other using XSI Type Extensions – which leads us to ask which is better? The unhelpful, fence-sitting answer is both have their advantages – while being a vast improvements on the DDI Note Element.

[DDI Notes] limit the ability for implementers to coexist with the future vision of the standard

Ultimately, Notes are the last way one would want to extend the DDI specification becuase they are wholly unstructured (despite the ironic fact that the Content of the Note is of a StructuredStringType). The content of this note can take any form – plain text, html, csv, even XML embedded within CDATA – and a receiving party, be it a person or software, will in most cases be none the wiser about the structure of the content. Given how far removed Notes can be from the extended object, the receiving party may not even be aware of any extension at all.

 The advantage is that users could create XML extensions, generate their documentation, push it upstream, and limit the amount of change in their own systems - its a clear case where self-interest helps everyone.

This lack of structure ultimately, removes any benefit of using a standard – to that point that in my own personal opinion, Notes should be deprecated as soon as practical. This is due to people being able to add Notes when a better approach within the standard is either difficult to find, or hard to match to existing legacy software. Furthermore, they limit the ability for implementers to coexist with the future vision of the standard. The two approaches I’ve illustrated conform to good XML practice and encourage good documentation of changes, but they also provide direct ways to extend the standard in sharable ways, while also providing starting points for future changes. Since both methods require creating XML Schema to properly document the extensions, it is not unfeasible that schema created in this way could almost be directly imported into new versions of the standard. The advantage is that users could create XML extensions, generate their documentation, push it upstream, and limit the amount of change in their own systems – its a clear case where self-interest helps everyone.

But, having gotten down from my high horse…

Substitution Groups give the ability to create entirely new custom objects, they are unable to be easily recognized by existing tools they are limited on where they can go based on the original and unchangeable schema. While on the other hand, XSI Extensions can be used anywhere and on any element, without causing trouble for existing tools, they can only add information to existing to help fill data gaps. Ultimately, it is up to the implement to weight these benefits to determine the correct approach, before sharing these solutions with the community to support maintained ongoing support for the standard.

Note: I should point out that in the second post on XSI:types I specifically singled out a Note use in the Colectica implementation of DDI that could have been rewritten as using XSI extensions. Since the above diatribe could be read as an overly harsh criticism of their use of Notes, I feel that it should be stated that notes within DDI exported from Colectica are well-documented and Algenta provided support that helped push the time taken element into DDI 3.2.