Re: XSD: Extensions

francis (francis@redrice.com)
Thu, 28 May 1998 14:29:42 +0100

Paul Prescod wrote:
>
...
>
> I'm starting to remember why I was so leery of schema extensibility in the
> first place. Essentially, we are running into the verification version of
> the "HTML Optimized for Netscape" problem. The solution to the HTML
> problem was XML+XSL -- extensibility and a way to define the results of
> extensions. The equivalent in SDD would have to be some way to "plug in"
> schema language extensions in a portable way (ECMAScript, Java?). This is
> way outside of our mandate. Thus, I think that these forms of extensions
> are also outside of our mandate.
>
...

May I hope that ECMAScript / Java plug-in processing is near the top of
the list for XSD 1.1? My backgound is in client-server and web-server
application development. My UI design goals are to make user interaction
with applications as productive and simple as possible - either to make
it impossible to enter invalid data (by graphical input, listboxes,
buttons etc) or to trap and report the errors as early as possible (when
they enter an alpha character into a numeric field; failing that, when
they tab off the field; failing that, when they complete the form -
abject failure is when you wait till the end of a five form business
transaction to tell the user they made an error on form one...).

Core XML simply doesn't allow the validation of basic data types (such
as numbers and dates), data lengths, data ranges, referential integrity
(despite IDREFs) or other logical constraints. While I can see that XSL
provides answers for two key questions (specifying the validation code,
and binding XML elements to code parameters), I would like to see a
simple, portable solution that (1) allowed validation semantics to be
specified outside Style sheets, and (2) depends only on browser support
for portable technologies such as ECMAScript and Java, even if this
involved an increase in server-side processing.

If you're writing a business application then validation must be in the
context of the application's semantics. It doesn't matter what
technology is used in what kind of layers - in the end, you can't accept
orders for non-existent parts, or from unrecognised suppliers (and
business error-messages should of course express this in terms of the
user's view of the transaction rather than the architect's view). This
is, I think, adequate justification for allowing validation constraints
- they are in fact sematically transparent, since they don't "create"
errors, they simply bring the error-trapping closer to the user, thus
making the application more responsive and more usable.

Francis.

-- 
Francis Norton


Old enough to remember free speech on the Internet?
Catch http://www.oneworld.org/index_oc/issue298/frank.html while you
still can. Or, indeed, if.