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

[Norman Gray <norman.gray@glasgow.ac.uk>]

Michael and all, hello.

On 4 Sep 2022, at 20:58, Michael Kay wrote:

> So you're seriously suggesting that just because no employee has ever earned a bonus of more than $1m, or has had a surname longer than 20 characters, your schema should impose these as upper limits?

I don't think that is what Roger -- or John Carnack in the remark Roger originally quoted -- is saying.  The discussion has drifted towards validation and away from the original rather interesting point about design, and limits.

To stick with the telephone number example (though I'm not sure it's the best one), you _could_ design a system which would deal with arbitrary-length phone numbers, but it would be more complicated than one which presumed all numbers had 12 digits, or which normalised input to 12 digits.  You'd be more likely to get the more general version wrong, it wouldn't be tested as thoroughly, and it wouldn't have any payoff, because you would expect to interoperate with other systems that presumed only 12 digits.  Thus, as a matter of engineering good taste, you might well decide against the generalised behaviour, and to hard-code 12 telephone digits in your system.

Such a decision is also reasonable because there's a standard which governs this, and if we ever get direct dial telephony to Mars, and the phone numbers get longer, we know that we'll be in for a couple of decades of software rewrites anyway.  So it's not an offence against engineering aesthetics to hard-code the string length.

In this context, the role of schema validation is to push this assumption as far forward in the input chain as possible (and you can do this validation well or very badly).  But the interesting thing here is not the validation -- where, when, how, or anything like that -- but the justification for the hard-coding.  The relevance of this example is simply, I think, to indicate that it can be justifiable _not_ to take an opportunity to be general, even if it's easy in a particular case.

Carnack's point, as I read it, was that there can be a value in deliberately not removing a software limit, or assumption, even when doing so appears to be 'free'.  If you hard-code a limit -- such as an array size -- with a limit which is an order of magnitude larger than anything you expect to see in practice, but you do encounter a situation where that limit is reached, then you do unequivocally want to know that, since a core assumption about the program is wrong.  He's saying, in other words, that this is (a softer version of) a code assertion: if the assertion fails, then the thing that can't happen has happened, the program has _already_ failed in some way, and you want the world to stop at this point.  That is, 'breaking' at this point in the future might be the right thing to do.

I"m not sure I 100% agree with Carmack here, but the point 'limits are a type of assertion' is not one I've come across before, and I think it's an interesting one.

(To be clear, I don't think that assert(n < ARRAY_SIZE) would be a good way to express this, because I believe assert() assertions should be invariants you believe to be mathematically/logically true about your program.  But if(n >= ARRAY_SIZE) fail_noisily("the world is upside down"); is legitimate and would have much the same effect).

>  You don't know what will happen in the future, but that doesn't entitle you to impose artificial restrictions to prevent it happening.

You don't know what will happen, but it may be prudent to guess what will happen _rather than_ trying to cope with anything that might happen, and if you do that, you may want to learn you're wrong very unambiguously.

Best wishes,

Norman


-- 
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK