On Tue, 20 Mar 2001, Wayne Bradney wrote: > No nerds around here - only geeks ;-) > > I've been considering the same issues recently -- and I'm left curious as to > why any system would want to play around with the schema reference of an > incoming document. If someone sends you a document that references a > particular schema, they're doing so for very good reason, they're telling > you that their document conforms to that schema. Of course you can use the > EntityResolver to point the way to a locally cached version and avoid the > network traffic, but in that case you'd better be sure that the cached > version is in sync with the referenced one.
There are two very different viewpoints here. One is the document-centric view, where the document tells you which schema it is valid against. In this case the parser can determine that the document is valid, but not necessarily that it is useful. The other view is the application-centric one, in which the application is expecting a particular type of message, and needs to force validation, even if the document doesn't specify a schemaLocation. Our system is necessarily application-centric, as we have several different versions of each of our schemas in circulation, all of which define the same namespaces. We need to check that the documents we receive are valid against *the latest version* of the schema, so we can't simply rely on them validating against their specified schema and having a root element in the correct namespace. The alternative would be to write another layer of validation which checks that the xsi:schemaLocation attribute exists and is correct, but since these can appear at various places in the document, we decided it was easier to patch xerces to allow us to override the schemaLocation. At the end of the day, xsi:schemaLocation was only ever intended as a hint as to which schema to use. Applications are free to ignore it if they know better. This also allows us to do away with the need for xsi:schemaLocation and xmlns:xsi attributes altogether, which in our experience cause endless confusion (remember we are dealing with non-specialists, many of whom have never seen XML before). Ian -- Ian Roberts, Software Engineer DecisionSoft Ltd. tel: +44-1865-203192 http://www.decisionsoft.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
