Re: [xml-dev] reasons why an XML instance must be validated with a XML s

["Fraser Goffin" <goffinf@googlemail.com>]

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@gmail.com> 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@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>