Re: Question on xsd:import

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:49:00 UTC