XHTML 2.0 – I hope its not more of the same.

This interesting article on XHTML 2.0 up on the IBM developerWorks site got me thinking. For me the acid test for XHTML 2.0 will be how strictly it parses content and how reliable the renderings are across the various browsers that are out there today.

I know a guy who works on a fairly popular web-browser at the layer between the abstract model that sits on top of it and he pointed out that the W3C really hasn’t had a good set of test cases for how things should work and render.

In fact, in one scenario they had to take test cases from a later specification and dumb them down to conform to the older spec, and even then there was a lot of wriggle room.

SW50ZXJuZXQgbWVtZT8=

VGhpcyBpcyBhIGNvZGVkIG1lc3
NhZ2UuIEl0IHdhcyBkb25lIHdp
dGggYmFzZSA2NCBlbmNvZGluZy
wgbm90IGV4YWN0bHkgY3J5cHRv
LCBidXQgSSB3b25kZXIgaG93IG
1hbnkgcGVvcGxlIHdpbGwgcmVh
ZCB0aGlzIG1lc3NhZ2UuIExldH
Mgc2VlIGlmIHdlIGNhbiBtYWtl
IGl0IGFuIEludGVybmV0IG1lbW
UsIHBvc3QgdGhlIHNhbWUgbWVz
c2FnZSB0byB5b3VyIGJsb2cgYW
5kIHRyYWNrIGJhY2sgdG8gdGhp
cyBvbmUu

In Sydney for the Week

I am in Sydney for the week presenting the first delivery our latest course – PROFESSIONAL .NET. I’m looking forward to getting into some of the material although funily enough this first pass is in VB.NET and those who know me will know how amusing that is.

Anyway – I’m looking forward to getting along to the Sydney Deep .NET User Group on Thursday evening and meeting up with the usual suspects!

Branch Structures at Microsoft

I love it when the crew from Microsoft post up details about their internal processes. This time its Brian Harry who has posted up about their existing source branch structure and what they hope to do when they move to TFS internally.

One thing that they do is break up the feature development into branches to reduce contention and the risk of someone inadvertantly breaking the build of another group in DevDev (Brian outlines some good stats why this is a real issue). If you want to know more about branching you can read my recent posts on the subject (1, 2, 3, 4) which cover off some of the techniques that the guys at Microsoft are doing to control the complexity of building what they do.

Anyway – some of the comments in Brian’s post are worth reading, including some of the critical ones. All in all however I think that once a development team reaches a certain size branching is inevitable and if you ever want to produce patches for your software without slipping in lots of bugs you are going to need it – even for a one man development band!

TFS is a repository for strongly typed design artifacts.

Brian Sherwin has posted up an insightful piece about VSTS not being able to help you unless you change your habits. In many respects Team System is a bit like SAP (except heaps cheaper) in that it offers an amazing opportunity to customise and thats what a lot of early adopters are going to do.

Once again, like SAP users, VSTS users are going to hit a stumbling block, but in this case I don’t think its going to be upgrade blockers, instead I think its going to be the fact that they have tried to graft their old processes onto a product which may have served them better in its default configuration.

One of the things that I have tried explaining to people is that VSTS provides an opportunity to reduce the dead tree usage in your organisation and store design and project management information as first class (and strongly typed) entities in the various TFS data stores.

If you insist on using the tools the way that they are supposed to be use AND continuing to produce your out-dated design artifacts then you are just wasting your time.