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

Re: A single, all-encompassing data validation language - good

  • From: "Chris Scott" <scott.chris@g...>
  • To: "Michael Kay" <mike@s...>
  • Date: Tue, 7 Aug 2007 08:47:33 -0400

Re:  A single
> occasionally 28 or 29. Does this refinement mean you are doing something of
> a fundamentally different nature? I think not. It does mean that you've
> crossed the limits of what can be done with a grammar-based approach, but
> surely we should make it as easy and seamless for people to cross that
> boundary as we can?

Perhaps I was a bit vague in my assertion of "fundamentally
different".  Yes, of course, it's valid to think of your the extension
in your example as being wholly inside the problem domain.  It's still
validation, of course.  I was hoping to hint that since assertion
based rules are not necessarily bound to any one point in a grammar,
then we should try to keep them as separate as possible.

In your example, it's easy to tie that assertion to the month
complex-type.  What if we have, however, a rule like

//@bodyType='Regular'/descendant::node()/@color =
/Factory/Chasis[@bodyType='Regular']/Colors/Color

under which node would we place the assertion declaration?  In plain
english I want to make sure for every part for a regular body that
needs a color, we have a Chasis station that can supply that color.
We could define an enumeration every color attribute, but the
manufacturer wants catalytic doodles in different colors than exhaust
spinners.  We also want to make sure the Chasis people don't retire a
color thats needed for the rear spoiler bug guard.  Finally, we
should have this failure report to the user to go call Color
management so they don't have to parse the rule.  Since we have
factories in several different countries we have stylesheets that
specify the text in the correct language.  Whew!

So where does this assertion pertain to in the grammar?

I'd argue that since such a relationship is non-trivial for many real
world rules, we should keep the assertion declarations separate from
the grammar specification, e.g. sch:pattern could be a sister element
to top level types, i.e. under xs:schema or perhaps a new top level
element  xs:patterns , but not else where. (this may be fairly small
point to argue, i know)

Why even put them in the same validation document then?  Because it's
incredibly convenient to do so, and as you pointed out, though it's
out of the bounds of the grammar-based approach, it's still terribly
relevant to having a valid document.

IMHO assertion validation is different enough to not be defined under
the same sub-tree, but relevant enough to be in the same validation
document.  If it meant getting Schematron included as standard in XML
Schema, though, I'd be happy to concede on this point.

~Chris


[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.