[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Service Constraints
We use an XML schema library that models the majority of the entities that we need to express business transactions. These typically can be quite large complex types that contain the superset of all properties for an entity. For example we might have a Customer complexType that has 20 or 30 elements. When we use these complex types within the context of creating a business transaction, there is an inevitable discussion about whether a type should be specialised for that particular context by applying greater constraints. For example, it might be that for a particular business service schema, only 10 of the elements in the Customer type are actually required, at least for now. So we could create a new Customer type within the service schema that only contains those 10. Others would prefer that the whole type is used and all of the elements in it's content model remain as optional. Part of the rationale for this is to minimise the possibility of having to deal with a breaking change to the schema some time in the future as/when requirements change and some of the excluded elements could be required. A case is also made for leaving the full type so as to provide a greater chance that the service schema will be more reusable, and that by applying greater constraints (not limited to just removing parts of the type but also tightening cardinality or applying facts and so on) makes the service contract 'brittle'. On the flip side, others prefer to have a service contract [schema] which applies the fullest set of constraints and give the user of that schema the best possible specification in terms of what data is expected and would be valid in the context of the business transaction. This is more in line with the concepts of 'consumer driven contracts' which often have the (desirable) characteristic of being much more communicative than schema that have few constraints (ie. are packed with mostly (or completely) optional elements of type xs:string of unspecified size or form). This subject often gives rise to some heated debate that somewhat predictably tends to centre around subjects such as versioning, compatible/incompatible change, integrity of the base data model, ease of use for service consumer, potential service reuse and so on... So I thought I'd invite members of this community to comment on whether you favour very open lightly constrained schema when defining business services (at least when expressing the data content as XSD) or whether you prefer to try and specify all constraints even at the risk of generating greater churn (aka: incompatible change). Fraser.
[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
|