Re: It is okay for things to break in the future!

From: Rick Jelliffe <rjelliffe@allette.com.au>
To: xml-dev <xml-dev@lists.xml.org>
Date: Mon, 5 Sep 2022 18:52:34 +1000

Play the video

I think analytical clarity is helpful.

If you know your schema will be long-living, you can try to organize it into ways that reflect the separation of concerns (i.e. respecting Conway's Law.)

So it is reasonable for the makers of a schema to have target capacity limitations, and for them to be part of a schema for validation. But it is necessary for the schemas to be capable of being organized that way: to provide hooks and methods where constraints and values can be overridden.

For example, consider the UBL Code-lists. These are lists that a schema uses, but which are maintained at a different cadence to the schemas, by different folk. That poses a maintainability issue if your schema language cannot look outside itself for data.

I don't see that changing capacity constraints over time, as the world evolves, is much of a different problem.

The obvious way for users of XSD to deal with these things is to have a base schema with minimal constraints and maximal openness, and then regular specific schemas that extend and restrict it, which provide those evolving details like system capacity constraints. Which treats schema evolution as a publishing problem. (Personally, I don't think it is good enough and you still need some homemade layer on top of it, but it goes some way. )

Regards

Rick

On Mon, Sep 5, 2022 at 5:48 AM Roger L Costello <costello@mitre.org> wrote:

Hi Folks,

Sorry, I don’t agree with the posts.

Here are examples that posters gave of things that developers have failed to account for:

- Didn’t account for London temperature rising to 40 degrees Celsius
- Didn’t account for employees over 90 years old
- Didn’t account for extensive use of international phone calls
- Didn’t account for workers under 16 years of age
- Didn’t account for last names containing a hyphen

There is a difference between:

- Failing to understand the current world and then writing incorrect and/or incomplete code
- Not knowing the future

My post was about the latter, not the former.

Damian actually gave an excellent example of the latter: Suppose in 1970 you created code to validate phone numbers. You could not have anticipated the arrival of mobile phones 30 years later. When mobile phones did arrive, you really want to know. You really want your validation code to fail. Whatever world view you had in 1970, it changed radically by 2000. A lot of changes will be needed in the system, validation code being one of them.

/Roger

References:
- Re: It is okay for things to break in the future!
  - From: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
- Re: It is okay for things to break in the future!
  - From: "Liam R. E. Quin" <liam@fromoldbooks.org>
- Re: It is okay for things to break in the future!
  - From: Roger L Costello <costello@mitre.org>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Subscribe in XML format

RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

XML Editor - Download a 15 Day Free Trial Now >

See What's New in Stylus Studio >

Buy Stylus Studio - XML Editor - Now >