Re: [xml-dev] It is okay for things to break in the future!

[Michael Kay <mike@saxonica.com>]

> 
> But if there is a bit in your code where there is effectively a queue (I'm struggling to find a good concrete example here), you might decide to implement the queue insertion with what is effectively a O(N^2) algorithm, because it's bulletproof, and N is never going to be more than a few.  The argument is saying 'Go ahead and do that -- don't beat yourself up -- _but_ it would be wise to think briefly about how big N can be, and wise to fix N, and to ensure the program deliberately fails with 'rewrite me!' when that limit is breached.'
> 

There are certainly cases where I decide to to assume that the number of attributes or in-scope namespaces on an element will usually be small enough that a quadratic algorithm is OK. But I certainly wouldn't use that as justification for putting an arbitrary limit of (say) 16 on how many attributes or namespaces you can have.

On the other hand, you do sometimes need to impose limits, e.g. a limit of 65536 on the number of distinct namespace URIs in a document. If you've decided that there are good engineering reasons for imposing such a limit, then fine, you need to fail cleanly if they are exceeded, and if that's done using schema validation, that's fine too. But that's a very different matter from imposing a limit of 16 because that's the most we've ever seen or the most we can imagine anyone wanting. 

Michael Kay
Saxonica