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

Re: Fwd: 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

Re: Fwd:  Not using mixed content? Then don't use XML
>> - 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]


PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
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.