This article will have to topics - one about extending OOXML using the built-in extension mechanisms and one about extending OOXML itself.
Using built-in mechanisms
As I have written about earlier OOXML has a (fun) part containing mechanisms for extending OOXML with vendor/domain-specific extensions. That part is "Part 3 - Markup Compatibility and Extensibility". The part describes different techniques when extending OOXML - most interesting is propably the sections about "Markup Compatibility Attributes and Elements" describing ways to extend OOXML while enabling compatibility to e.g. earlier/current version of the specification.
So if you were a vendor wanting to add something to the spec - but couldn't wait for the slow ISO pace or simply needed the competitive edge of not revealing anything about future software releases to your competitors ... what could you do?
The first thing you should do is to decide if you want your new stuff to eventually make it into the spec. If you don't want that - you're done already.
Assuming you want it into the spec, here are a couple of hints to how you might approach it:
- Document your extensions thoroughly
- Present these extensions to SC34/WG4 with justification to how and why you want it into the spec
- Work with us to polish the nitty-gritty details that you overlooked
- Make sure there are no legal nor technical barriers to implementing these new features for your competitors
- Wait for the stuff to eventually be included in IS29500
So the real target of this is - if you haven't already guessed it - Microsoft. So to be even more specific, here's a little list of things to do for Microsoft - in case they want to extend IS29500:
You will propably have some additions to IS29500 in your implementation of Office 14. Assuming that you will at some point like these to be added to IS29500, this is what you should do:
- Document your extensions thoroughly. Remember, the quality of the documentation will be under the same scrutiny as the text of DIS29500 so please do it right the first time.
- Add the documentation of your extensions to your "Implementer's notes" on the DII-website.
- Present these extensions to SC34/WG4 with justification to how and why you want it into the spec.
- Work with us to polish the nitty-gritty details that you overlooked.
- Include the extensions and the documentation for it in your OSP.
- Wait for the stuff to eventually be included in IS29500.
Remember, the minute the first public beta of Office 14 hits the web, the documentation of the extensions as well as inclusion in OSP should be finished. Not a month later, not a week later - on day one!
Extending IS29500 itself
There has been a lot of talk lately to how IS29500 will be extended in the future. Specifically, how - and where - will new additions be included? IS29500 is comprised of two schema sets - a strict set and a transitional set. Currently the strict set is created from the transitional set, so strict is in fact a proper subset of the transitional set.
However - there is no guarentee that this will always be so.
My gut feeling is that transitional should be preserved as the "reflection" of the existing Microsoft Office documents (until March 2008) - in other words in term with the scope of IS29500. I think that any new stuff should be added to the strict schema set only. The term "transitional" clearly implies this. As I recall the feeling in Geneva at the BRM, the idea behind the transitional set was, that eventually it would no longer be needed and hence removed from the standard - at some point in the future. If we continue to add new features to the transitional set, we will never get to the point where we can honor the sentiment of this particular issue.
... now at the moment, we haven't decided anything yet ... so right now anything goes.
But what are your thoughts?
Subscribe