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

Re: Question on xsd:import

From: Jacek Kopecky <jacek.kopecky@systinet.com>
Date: Wed, 17 Sep 2003 19:57:16 +0200
To: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
Cc: WS-Description WG <www-ws-desc@w3.org>
Message-Id: <1063821436.2097.71.camel@localhost>

Roberto, my bad, I didn't notice you said your schema would include (not
import) the chameleon schema. With include it would work, yes.

Jacek

On Wed, 2003-09-17 at 19:45, Roberto Chinnici wrote:
> Why wouldn't it work? The chameleon would be xsd:include-d into a schema
> that is either defined inline or imported by WSDL, so the components
> it defines would be visible to the WSDL document. Sections 3.1.1 and 3.1.2
> spell this out; e.g., section 3.1.1 says: "Note that only components defined
> in the [imported] schema itself and components included by it via xs:include
> are available to WSDL".
> 
> Roberto
> 
> 
> Jacek Kopecky 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
> 
Received on Wednesday, 17 September 2003 13:57:20 GMT

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