XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] How to measure the changeability of an XML Schema?

On Tue, Jan 18, 2022 at 8:47 PM Roger L Costello <costello@mitre.org> 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


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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS