W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2004

Re: Followup: multiple services sharing a name

From: David Booth <dbooth@w3.org>
Date: Thu, 15 Jan 2004 11:23:58 -0500
Message-Id: <5.1.0.14.2.20040115103720.01fd9430@localhost>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:28 GMT