Next in thread → Next in month →

Re: [xml-dev] How to measure the changeability of an XML Schema?

From
Mukul Gandhi <>
To
Roger L Costello <>
Date
2022-01-19T06:47:54Z
ID
<CANGHzgBsZmqqwK3x1cnE8cHhH+0dyYDP9nSZ=>
Thread
Re: [xml-dev] How to measure the changeability of an XML Schema?
On Tue, Jan 18, 2022 at 8:47 PM Roger L Costello <[email protected]> wrote:

I would like to create an XML Schema that conforms to a list of principles. One of the principles is this:

Design the schema so it can be easily changed
              when requirements change.


I agree.
 

Consider a schema that uses a large inheritance tree (derive-by-extension and/or derive-by restriction). A change to complexType ABC impacts every complexType under ABC. If a requirement change applies only to ABC and not to any of its descendants (or applies to a subset of its descendants), then the schema is resistant to changes.

Assertion: Inheritance trees are evil. They create schemas that are resistant to changes. The deeper the inheritance tree, the more brittle the schema. Want schemas that are easily changed when requirements change? Then don’t use inheritance trees.


I think that, just because an XSD (deep) type inheritance is hard to change when requirements change, should not be the only reason, that they shouldn't be used. Using features, like XSD type inheritance, is also quite much guided by the requirements unique to use cases/domain.
 

Next, consider a schema that declares an element XYZ to be mandatory (minOccurs="1"). If a requirement change says XYZ is optional, then XML instances that conform to the previous schema are suddenly invalid.

Assertion: Mandatory elements are evil. They create schemas that are resistant to changes. Want schemas that are easily changed when requirements change? Then don’t make elements mandatory.


I think that, changing something within a schema from non-mandatory to mandatory, would be hard to do, since existing data within XML documents would result as invalid after the schema change.

I think that, syntax like xs:override within XSD 1.1 are a good, way to define completely new XSD types with same name as before.
 

--
Regards,
Mukul Gandhi
Next in thread → Next in month →