[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Service Constraints

  • From: Fraser Goffin <goffinf@gmail.com>
  • To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
  • Date: Fri, 8 Apr 2011 23:17:46 +0100

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).


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


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

Buy Stylus Studio Now

Download The World's Best XML IDE!

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

Don't miss another message! Subscribe to this list today.
First Name
Last Name
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.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.