Re: Question on xsd:import

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

Received on Wednesday, 17 September 2003 08:58:52 UTC