Re: XSD: Extensions
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. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format