[
Lists Home |
Date Index |
Thread Index
]
From: "Mike Champion" <mc@xegesis.org>
> So sure, a "contract" specifying the format of data is useful (more useful for design,
> negotiation, and debugging purposes than for run-time validation IMHO). Doing as
> much as feasible at the syntactic level with regular expressions / schema / etc. makes
> a lot of sense in *many* circumstances, so sure, people should be encouraged to
> use these features WHEN they solve their problems "out of the box."
> But in
> many (most?) real-world situations there is no XML formalism to to define the
> contractual constraints appropriately, and the contract must include natural
> language descriptions, references to mathematical concepts ("primeness"),
> database relationships ("the customer id must exist in the database, the
> customer record it identifies must match the information supplied in the order").
> So, few would disagree that "it's in the contract". Lots would disagree that
> the amount of effort/complexity added to XML++ to validate the "contract" with
> schema-based mechanisms is worth the cost.
So aren't you saying we actually need a way of making natural language assertions
(as might be found in a contract), with a machine-executable way of exercising them,
including basic mathematical operations the ability to cross-check values (even values
available from external URLs)? And that such a solution should not be complex?
Why isn't this Schematron? It does not start with a grammar abstraction or the noxious
supposition of data being a tree getting in the way of clear expression. There is
a divide between clear expression (in natural language) of an assertion and the
implementation (in XPaths) of that expression.
> (Ahem, the option of "we don't want your money until you enter the data to
> our exacting standards" appeals to nerds a LOT more than it appeals to Pointy Haired
> Bosses!).
On the other hand, it is increasingly important for suppliers of software to be able
to demonstrate to clients/purchasers/investors that they have proper quality programs
in place. ISO 9000 and so on. Contracts for software may specify metrics such
as commented lines of code or MacCabe cyclomatic numbers, especially now that
there are harder numbers out[1]. And Java programmers who get used to JUnit
unit testing sometimes find it so useful that they push for it harder than their managers
even.
Cheers
Rick Jelliffe
[1] Anyone involved in industrial OO programming could do welll by familiarizing themselves
with NASAs review of metrics at
http://sel.gsfc.nasa.gov/website/sew/1999/topics/rosenberg_SEW99paper.pdf
which my company has found very useful.
|
