[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: Fwd: [xml-dev] Not using mixed content? Then don't use XML
- From: Fraser Goffin <goffinf@gmail.com>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Tue, 9 Apr 2013 20:33:04 +0100
>> - provide 3rd parties with the parsing side of your app, so they can
>> verify the xml using that ?
We have had some success with this approach. Sort of in-line with part
of the idea behind 'consumer driven contracts'.
> 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.
Well, I do agree with the point about having conversations. Indeed
entering into any trading partner agreement requires a good deal of
collaboration, some of which is aided by technical artefacts as well.
As you point out examples of XML instances are also helpful, but not
in isolation.
I still feel that having an executable language can be really
powerful. My experience of Word document specification is probably the
same as everyone else's. They start out OK (if you can get people to
sit still long enough to read them and not use them as a way of
beating you over the head if your implementation isn't exactly as its
written). But quickly they get out of date and end up riddled with
ambiguity and mis-interpretations.
Perhaps using a DSL is an approach with merit ? BDD provides
vocabularies like Gerkinn which if you add you own domain language,
can help to bridge some of these difficulties ... well maybe... jury's
still out for me
Fraser.
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
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]