Cart
[Home] [By Thread] [By Date] [Recent Entries]
Yes this is already an interesting conundrum between co-locating business rules with its associated maintenance issues, versus providing the best chance that the message received is business processable. The reality (as usual) is 'it depends'. For example, protecting the integrity of a business applications' data should (imo) really be the responsibility of that application. However in some cases applications don't do a terribly good job of this particularly if their original set of usage models didn't include exposing business functions to external clients (i.e. they were designed in a tightly coupled way with a bunch of assumptions about their callers). In that case (and especially if you don't own the application source code) you may choose to implement validation in the receiving layer. In a case where a business application *does* provide integrity protection, you may still implement validation earlier in the processing chain but more as an optimisation to avoid chewing expensive processing cycles when it may be possible to determine validity earlier. Similarly, some business processes are asynchronous, in which case waiting 2 days for a response that only tells you that the date-of-birth field contained invalid data, is probably not going to encourage use of your service from your business partners, or commend you to your business pay-masters. As others have mentioned, the location and type of validation performed also depends on who the calling clients are and the level of 'trust' / assumptions that can be made. This can range from 'total' (no validation required) to 'none', and most points in-between. A constant theme on this group has been the idea of using different approaches to validating different aspects of messages. Hence XML schema might be OK for certain types of structural and some content constraint checking, whereas Schematron and indeed any other type of programmatic method can implement a broader range of tests. Pipeline processing and NVDL might be relevant here. I also agree with Rick's comment about open schema, and having different schema for different parts of the process, some of which may declare more/tighter constraint than others (sort of graduation of filters if you like). This can often depend on who owns the vocabulary (and sometimes who can extend it). For example an industry wide schema might have a great deal of optionality to cater for a wide range of implementer needs, however, each individual implementing organisation is likely to have aspects where they want to apply more constraint (e.g. making some information items mandatory that the market schema declares as optional) and vice-versa. It depends on the specific requirements of the receiving business process(es). To return to my original point (and one that others have made). The tough choices are sometimes about how much validation to put in 'up front' to provide an efficient and 'caller friendly' service without transplanting all of the business rules from the back-end into the front ! When all's said and done its about 'doing business'. The easier you can make this the better, but that said, its nigh impossible to 'fix up' invalid messages. At best thats just guess-work, at worst it might land you in legal difficulty. Thats why we get paid loads of cash right ;-) Fraser. On 10/09/2008, Andrew Welch <andrew.j.welch@g...> wrote: > > why should we use XML schema to validate XML? > > I'm interested to know how people decide what is a sufficient level of > checking in the schema, compared to the application... > > Do you do as much as possible in the schema, which could be a lot in > 1.1? Where do you draw the line? > > Do you do still write your application as though the XML isn't > validated, or do you rely on it? > > For example, a startDate and endDate - do you check that the endDate > >= startDate in the schema, in the application or both? Would you > bother with a decent error message "the end date must not be before > the start date" when that code is effectively unreachable if the XML > has been validated...? > > If you are doing the check in the application, then do you still do > the check in the schema - making it more complex and slower? A custom > application exception is a lot nicer than validation failure > message... :) > > However what's the point in partially processing XML, letting it get > to the application, when you could know that it would fail from the > validation level... > > you get the idea :) > > > -- > Andrew Welch > http://andrewjwelch.com > Kernow: http://kernowforsaxon.sf.net/ > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@l... > subscribe: xml-dev-subscribe@l... > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
