Lists Home |
Date Index |
Cox, Bruce <Bruce.Cox@USPTO.GOV> asks:
> I, for one, am very interested in discussing these issues
> further. Since XML Schema data typing cannot express all the
> business rules that constrain, for example, patent document
> numbers (from about 100 issuing offices), what other
> technologies can be invoked that would? What combination of
> technologies should be used, and in what order, to accomplish
> the goal? I'm interested in standards-based technologies,
> such as XML Schema, to express such rules in a fashion that
> removes as much variation as possible among systems that
> implement them around the world. Should we use a repository
> for the rules and their implementations?
> Is anyone else interested?
I think it's a question of layers of validation. Not everything should
be expressed at the XML schema level and not everything can be expressed
using a single method. For us, the business rules validation is what
matters and that's done in Schematron far removed from any level of XML
So, a discussion of what layers are needed, and how best to implement
them and should the relationships of the layers to each other be
formalized and should there be best practices on when to invoke the
various layers would be interesting. OTOH, trying to determine how much
business level validation to drive into XML schema sounds like a
> Bruce B. Cox
> U.S. Patent & Trademark Office
> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:firstname.lastname@example.org]
> Sent: Friday, August 13, 2004 12:35 PM
> To: 'Roger L. Costello'; email@example.com
> Subject: RE: [xml-dev] Are people really using Identity
> constraints specified in XML schema?
> Michael is right, but this isn't a one size fits all decision.
> Loose filters allow dirt to seep into the system. The
> architectural question is what are the right places to put
> such rules into a system? We are aware of different
> technologies for this, and it is a good thread to out the
> issues if that interests the members of this list.
> That a technology can accomplish a task doesn't mean it is
> the right tech for that task. It doesn't mean it isn't.
> I suspect this is another task situatedness issue, but given
> a services architecture, one might want to inquire about
> tasks relative to their roles in distributed processes that
> are candidates for orchestration.
<snip>original query and answer about identity constraints</snip>