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

[Stephen D Green <stephengreenubl@gmail.com>]

It sounds like you are trying to develop a blind system. It is a
system like the white cane of a blind or visually impaired person. On
one hand the limitations of your system are so obvious to an outsider,
in this case a system user, that they can make the adjustments that
your system cannot make (like going off and using a different system).
On the other hand your only feedback comes just as your system is
about to walk into an obstacle (such as a change to from base ten to
base eleven some time in the future :) ). This reminds me of the
limitations of the functional paradigm and immutable, stateless
systems which only know their inputs and are blind to everything else
and assume there will be no need to change the function itself, so the
function must always produce the same output for the same input. It is
a system blind to state and sometimes to much of its context (unless
that is passed in like input). A more powerful system would detect
context such as the language of the user, the local settings, the
character sets available besides the one being used (so it would know
what a Euro currency sign is even if the character set did not include
it) and it would be able to query a database to find out whether there
have been recent changes to your address which might better match the
validation requirements of, say, the address the user is providing. If
you want your system to be partially sighted, OK, but do not make it
the law. It is not sensible to most people to deliberately design a
system so that it breaks when it meets an obstacle instead of
foreseeing it and adjusting for it. Nor is it sensible to develop a
system that to a user of it clearly cannot cope with anything but the
simplest requirements, has no flexibility and demands that decisions
come from the user, at a level of whether to use the system or abandon
it completely.
----
Stephen D Green

On Tue, 30 Aug 2022 at 12:18, Roger L Costello <costello@mitre.org> wrote:
>
> Hi Folks,
>
> Scenario: You are designing an XML Schema for validating XML instances that contain Book data. Each Book element contains Title, Author, Date of Publication, and ISBN. Some Books have multiple Authors. In your current environment, in your current worldview, no Book has more than 10 Authors. So you constrain the Author element to maxOccurs="10":
>
> <xs:element name="Author" maxOccurs="10" type="…"/>
>
> But what if in the future there are Books with 100 Authors, then XML instances will fail validation. Should you set maxOccurs to unbounded?
>
> No!
>
> Here’s why:
>
> You want to be informed when the world has changed, when the choices you made are no longer relevant. A world in which Books contain 10 times more Authors than you thought they would is a different world. You want to be informed of this. Your XML Schema was originally written with one world view, if validation starts breaking that means you have got to rethink the initial stuff.
>
> There is an analogous situation in programming. Should you constrain the size of an array or make it variable length? Here’s what John Carmack says: (https://youtu.be/I845O57ZSy4?t=4005)
>
> I'm kind of fond in a lot of cases of static array size declarations. I went through this period where we should just make everything variable length because I had this history in the early days where Doom had some fixed limits on it and then everybody started making crazier and crazier things and they kept bumping up the different limits -- this many lines, this many sectors -- and it seemed like a good idea that we should just make it completely generic so it can go up to whatever. There are cases where that's the right thing to do, but the other aspect of the world changing around you is it's good to be informed when the world has changed more than you thought it would. If you've got a continuously growing collection, you're never going to find out. You might have this quadratic slowdown on something where you thought “Oh, I'm only ever going to have a handful of these,” but something changes and there's a new design style and all of a sudden you've got 10,000 of them. So I kind of like in many cases picking a number, some nice round power of two, and setting it up in there and having an assert saying “Hey, if you hit this limit, I need to know.” When that occurs, you should probably think: “Are the choices that I've made around all of this still relevant if somebody's using 10 times more than I thought they would? This code was originally written with this kind of world view, with this kind of set of constraints, and I was thinking of the world in this way.” If something breaks that means I’ve got to rethink the initial stuff.