- From: David Booth <dbooth@w3.org>
- Date: Thu, 15 Jan 2004 11:23:58 -0500
- To: www-ws-desc@w3.org
- Cc: Amelia A Lewis <alewis@tibco.com>
Amy, You presented two scenarios: one using XML Schema import, one without. Let me address them separately. 1. In the case WITHOUT using XML Schema import, as I understand it the scenario you're presenting is as follows. You would have one XML Schema per country code, and a given XML document would be validated against the appropriate XML Schema, based on prior knowledge of the country code. In this case, it seems to me that you would probably also have one more "generic" XML Schema that uses "any" for the postal code area. So the processing sequence would likely go like this: (a) A normal XML parser validates the document against the generic XML Schema; (b) Application code grabs the country code from the document, looks up the appropriate country-specific XML Schema; (c) a normal XML parser then validates the document against the country-specific XML Schema. This looks fine to me. I see nothing here that violates any Web architecture, namespace or XML Schema principles. It looks like a reasonable way to transcend the limits of XML Schema for a particular application. 2. In the case of using XML Schema import, as I understand it the scenario you're presenting is as follows. You would have only one XML Schema, but it would contain a (single) import statement. Based on the value of the country code attribute, the effect of the import statement would vary: it would cause the appropriate XML Schema fragment to be imported for that particular country code. The problem with this scenario is that it would require a customized XML Schema processor that would have to contain application-specific knowledge to know that it should perform the "import" differently based on the value of the country code attribute. It could not be done with a regular, off-the-shelf XML Schema processor. In other words, the semantics that you'd be ascribing to the XML Schema document would be beyond what XML Schema specification says. >From: Amelia A Lewis <alewis@tibco.com> >Date: Wed, 14 Jan 2004 15:01:57 -0500 >To: WS Description List <www-ws-desc@w3.org> >Message-id: <20040114150157.74d3d910.alewis@tibco.com> > > >Heylas, > >It occurs to me that it might help to clarify this issue by offering a >sample from another domain, so long as the analogy is strong and clear. > >In W3C XML Schema, one of the most often-requested features is what is >labelled as "co-occurrence constraints." The requesters of this >functionality, on the whole, don't use this label, but the folks who >answer the FAQ use the label as a shorthand. Briefly, the usual request >is that the content model of an element be dependent upon the value >assigned to an attribute. This would be similar to a discriminated >union in C, for instance. An example: based on the value of the >country-code attribute (defined to be an enumeration of ISO country >codes), the value of the child element <postal-code> should conform to >an appropriate pattern (patterns exist for US, UK, etc., etc.). > >This is not permitted in W3C XML Schema. Can't be done, is the answer. > >Here's another answer, which I believe to be analogous to what David has >proposed: > >Create a schema for each country code. Give them all the same >targetNamespace. Give each a fixed value for the country-code >attribute, and specify the content model of the appropriate country. > >In fact, you could extend this a bit, since it's so useful, and make >these all schema fragments, with identical targetNamespaces, and have a >single import statement. Since any given schema processor ultimately >resolves only *one* of these imports, it's clearly a valid and viable >workaround for this annoying restriction in WXS, which places the burden >of choosing the correct bit to import on the catalog processor. How >this happens is not of interest to us schema folks; it's the province of >catalog designers/developers. > >Roughly the same issue exists without an import, if one simply creates >multiple same-namespace schemas with different content models, varied >based on the value of this attribute. Again, it becomes a problem not >for the schema validation engine, but for the catalog, which has to >supply the "correct" schema for a particular instance document. > >This would be an interesting proposal to make to the WXS WG. Would they >be as "neutral" to such a workaround as we have proposed to be on >multiple definitions of a service, varying on the occurrence of the >interface attribute? > >Amy! -- David Booth W3C Fellow / Hewlett-Packard Telephone: +1.617.253.1273
Received on Thursday, 15 January 2004 11:24:09 UTC