Ian, Well put. It's interesting that your system validates against the latest version of the schema, but for us that would defeat one the biggest advantages of using XML in the first place: the loose coupling of client and server applications. If we allow the client to specify which version of the schema it's message conforms to, it allows our server to support multiple versions of the protocol, which in turn allows us to avoid "lock-step" upgrades of client and server code. As long as later versions of the protocol are backwardly compatible (ie. additive or type changes only), enhancing the services provided by the server does not _require_ immediate changes in the clients -- they can upgrade at their leisure. I suppose in this respect our system is document-centric.
If you don't mind my asking, what mechanism _do_ you use to determine which schema to pick for validation, and then subsequently validate the document? Thanks and regards, Wayne M. Bradney Wall Street Systems, Inc. 30 Broad Street, 24th Floor New York, NY 10004 Phone: +1 (212) 401 8239 E-Mail: [EMAIL PROTECTED] -----Original Message----- From: Ian Roberts [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2001 4:46 AM To: [EMAIL PROTECTED] Subject: RE: Validation of an XML against Schema 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
