Re: Fwd: [xml-dev] Not using mixed content? Then don't use XML

[Fraser Goffin <goffinf@gmail.com>]

> No.  I would propose moving the other direction, treating all of the
> rules as "business" and not relying on schema for any layer of that.

Hallelujah something we can agree on. The business application should
always be the repository of business rules and validation is one
aspect of that. I only consider XSD useful as an optimisation so that
you don't consume cycles only to find something that you could have
discovered at the front door. This is especially true for cases where
the business application isn't 24/7 but you want to ensure customers
can still trade at any time and have a reasonable prospect of a
successful transaction. Typically I don't use XSD for the purpose of
validation all that much (although I might be more persuaded by v1.1),
since it's often much too blunt a tool for that and too difficult to
organise for anything more than simple grammar checking. I do find
utility for it elsewhere though.

On 09/04/2013, Simon St.Laurent <simonstl@simonstl.com> wrote:
> This is nicely concrete.
>
> On 4/9/13 4:45 AM, Andrew Welch wrote:
>> One issue I still haven't found a good solution or answer to is when
>> you have additional 'business rules' validation performed by the
>> application:
>>
>> - application parses the xml and validates it using the xsd
>>
>> - the application then performs some additional validation of 'business
>> rules'
>>
>> This has the following problem:
>>
>> - the xsd alone isn't sufficient for a 3rd party to check the xml will
>> parse successfully
>>
>> Do you then:
>>
>> - move all the business rules into the XSD ?
>
> No.  I would propose moving the other direction, treating all of the
> rules as "business" and not relying on schema for any layer of that.
>
>> - provide 3rd parties with the parsing side of your app, so they can
>> verify the xml using that ?
>
> The only advantage I can think of to this proposal is that it makes
> sharing schemas seem easy by contrast...
>
>> If you add all the business rules to the XSD, you then leave the 3rd
>> party to decipher cryptic xsd failure messages- cvc-complexType
>> anyone?  The 3rd party would much prefer some human readable docs,
>> rather than learn XSD.
>
> That last sentence is the key.  Too much of computing these days seems
> aimed at abolishing conversations among humans.  Docs are a perfectly
> adequate way to convey your intent.
>
> Whether or not the other party wants to track your intent is a harder
> question.  Powerful bureaucracies tend to have little interest in your
> intent (unless you are comparably powerful).  Peers and newcomers may
> have interest, and may even be able to help you improve what you're
> asking for.
>
>> Then, do you just expect the xml to be correct in your application, or
>> do you still perform the business rule checks?  The reality of the
>> situation is you have to perform the checks again, so then you open
>> yourself up to a mismatch between xsd and application.  You would of
>> course much prefer to provide the user with tailored errors messages,
>> they would prefer that too.
>
> I would argue for piling it all into business rule checks, with special
> emphasis on generating meaningful messages - not to mention an
> opportunity for human intervention so you have a sense of what's going
> weird.
>
> Even "at scale", these things don't have to be fully automatic.  Partial
> automation goes a long way, especially when it can improve over iterations.
>
> At least that's what the traveler's tales of the last fifteen years say
> to me.
>
> --
> Simon St.Laurent
> http://simonstl.com/
>
> _______________________________________________________________________
>
> 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
>
>