W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2003

Re: Question on xsd:import

From: Amelia A. Lewis <alewis@tibco.com>
Date: Wed, 17 Sep 2003 10:50:56 -0400
To: Jacek Kopecky <jacek.kopecky@systinet.com>
Cc: Roberto.Chinnici@Sun.COM, mgudgin@microsoft.com, www-ws-desc@w3.org
Message-id: <20030917105056.0168c534.alewis@tibco.com>

I do not have a strong opinion on this.  Providing the ability to coerce
means that a small number of additional W3C XML Schema instances are
usable, that otherwise would not be.  The only reasonably alternative
that I can think of is to absolutely exclude any schema that does not
contain a targetNamespace declaration.  Either of those solutions seems
okay to me; the original draft, as I recall, simply attempted to allow
as much in as possible.

Amy!
On Wed, 17 Sep 2003 14:58:47 +0200
Jacek Kopecky <jacek.kopecky@systinet.com> wrote:

> Roberto, IIRC the technique you describe below would not work as WSDL
> doesn't see stuff that's imported into schemas that are inside the
> types section.
> 
> I think the status quo is about as hacky as chameleon schemas
> themselves and so I don't see a reason to change it.
> 
> Best regards,
> 
>                    Jacek Kopecky
> 
>                    Senior Architect
>                    Systinet Corporation
>                    http://www.systinet.com/
> 
> 
> 
> 
> On Tue, 2003-09-16 at 23:19, Roberto Chinnici wrote:
> > Amelia A. Lewis wrote:
> > > On Tue, 16 Sep 2003 09:59:11 -0700
> > > Roberto Chinnici <Roberto.Chinnici@Sun.COM> wrote:
> > > 
> > >>Amelia A. Lewis wrote:
> > >>
> > >>>On Tue, 16 Sep 2003 03:11:09 -0700
> > >>>Martin Gudgin <mgudgin@microsoft.com> wrote:
> > >>>
> > >>>
> > >>>>This text first appeared in wsdl12.xml CVS revision 1.34.2.2 as
> > >part>>>of the types work ( it was subsequently merged into the main
> > >branch>>
> > >>>in>version 1.35 ). It was part of the write up that Amy did, I
> > >think.>>
> > >>>>Note that this ONLY applies to schemas that DO NOT have a target
> > >>>>namespace. It cannot be used to override the namespace of an
> > >>>
> > >>>imported>schema document that DOES have a target namespace. The
> > >text>>
> > >>>>essentially means that all schemas constructs are qualified. I
> > >can't>>>remember the rationale for allowing this, perhaps Amy will
> > >have>>
> > >>>better>powers of recall.
> > >>>
> > >>>
> > >>>As I recall, this deals with XML Schemas that were originally
> > >>>designed for use as "chameleons", and it also provides a pattern
> > >for>>use with other schema languages (for instance, the DTD example
> > >uses>>a similar technique to place all of the elements imported
> > >into a>>single namespace).
> > >>
> > >>Yes, but the dtd:import element is brand new, so we can assign it
> > >an>arbitrary semantics. It worries me that we're redefining how the
> > >>xsd:import construct works. This new functionality doesn't seem to
> > >>be too well defined either.
> > >>
> > >>For instance, wouldn't the clause "as if it contained a
> > >corresponding>targetNamespace declaration" be likely to break the
> > >references between>components in the imported schema? After all, if
> > >I did literally what>the spec says, i.e. read the schema in, ran a
> > >transform on it to set>its targetNamespace attribute to the desired
> > >value, then processed the>resulting document per the XML Schema
> > >spec, I'd most likely run into>some invalid references.
> > > 
> > > 
> > > Entirely possible, with a complex schema.  Solution is to
> > > namespace the schema internally.  If it isn't editable, and
> > > doesn't have a namespace, and breaks when a namespace is imposed,
> > > it's not usable.
> > > 
> > > 
> > >>By the way, I'm not sure what you mean by "chameleons". Could you
> > >>clarify that?
> > > 
> > > 
> > > No.  Google for it; it's a sufficiently complex topic that we
> > > don't need to go into it here.
> > 
> > Done, thanks. The references I found tell me that these chameleons
> > are quite a hack, that there are indeed problems with references to 
> > components within them and mostly that you shouldn't use them. Given
> > all this, I see even less of a reason to invent a new xsd:import
> > construct just to accommodate them. The workaround of defining your
> > own schema, have it include the chameleon and then xsd:import it (or
> > inline it) in your WSDL seems entirely acceptable, and from my point
> > of view is preferable to having the WSDL spec step into XML Schema's
> > territory.
> > 
> > Roberto
> 
> 
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Wednesday, 17 September 2003 10:54:56 GMT

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