RE: import/include

Sorry, I didn't realise you were asking for the reasons. Here is how I
see it:

Conceptually speaking both constructs act at the component level to add
components such as element declarations, complex types etc. to the
schema component itself. One, include, is used to assemble a schema from
components from multiple schema documents but a single namespace. The
other, import, is used to assemble a schema from components from
multiple namespaces. Note that nothing is said about schema DOCUMENTS
with respect to import. A schema processor could construct schema
components from some other source ( programmatic types, database schema,
just 'knowing' ( having hard-coded info ) about certain components ).

Looking at the lexical rep then the following applies:

|-----------|----------- |-----------|
| Construct | namespace  | location  |
|-----------|------------|-----------|
| import    | optional   | optional  |
|-----------|------------|-----------|
|include    | prohibited | mandatory |
|-----------|------------|-----------|

Now the reason namespace is optional on import in XML Schema is that you
can import components that DO NOT have a target namespace into a schema
that DOES have a target namespace. So presence or absence of a namespace
attribute is not enough to tell a schema processor whether the schema
being 'brought in' should have the SAME target namespace, NO target
namespace or a DIFFERENT target namespace. So schema has two constructs,
one of which says 'target namespace MUST be the same', the other of
which says 'target namespace MUST be different'. For import, the schema
processor checks that the value of the namespace attribute DOES NOT
match the value of the targetNamespace attribute of the importing
schema. For include, the processor checks that the value of the
namespace attribtue DOES match the value of the targetNamespace
attribute of the including schema.

Another reason is that two constructs actually makes things a bit easier
to validate.

Some observations:

1.	I suspect people will want to construct WSDL components from
things other than XML Infosets, so I think location should be optional
on import.

2.	In WSDL we do not have the 'no target namespace case' so the
grid can be modified:

|-----------|------------|-----------|
| Construct | namespace  | location  |
|-----------|------------|-----------|
| import    | mandatory  | optional  |
|-----------|------------|-----------|
|include    | prohibited | mandatory |
|-----------|------------|-----------|

So it now appears that presence or absence of a namespace attribute is
enough for us to know whether a same namespace or different namespace
operation is being performed. But with same namespace location is
needed, whereas for different namespace location is optional ( see 3 )

3.    Having two constructs makes a WSDL document easier to validate.
wsdl:import always has a namespace attribute, location is optional.
wsdl:include never has a namespace attribute, location is mandatory. If
we roll up into a single construct then we would have to say something
like:

	If namespace appears then location is optional
	Else if namespace does not appear then location is mandatory

Also people could say <wsdl:mergedimportandincludeelementname/> and that
would be legal per the schema type for that element, but non-sensical.

Alternatively we could make namespace mandatory and say that you have to
put the targetnamespace URI of the including WSDL in order to do a SAME
namespace operation. But that makes validation difficult, because you'd
have to say something like:

	If namespace == targetNamespace then location is mandatory
	Else location is optional

So on balance, I think that we have less motivation for two constructs
than schema, because of the lack of the 'no target namespace' case. That
said, I think we still have some motivation, in terms of making the
constructs easier to write and harder to get wrong.

Hope this helps,

Gudge

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: 11 October 2002 01:16
> To: WS-Desc WG (Public)
> Subject: import/include
> 
> 
> 
> I heard from Arthur that there was a proposal to do
> include/import following the XSD approach precisely. Before 
> getting to that, I'd to see an answer to the following which 
> I sent a few days ago:
> 
> > > "Martin Gudgin" <mgudgin@microsoft.com> writes:
> > > I think the cleanest solution is to spec wsdl:import and
> > > wsdl:include the same way the xsd versions work. That way things 
> > > work the same way in the wsdl: section of the document as 
> they do in
> > > any xsd: sections of the document.
> >
> > Assuming that you guys had good rationale for creating two
> different
> > constructs for the two cases in XSD, I would have to agree.
> >
> > I was against <include> earlier on the basis that one
> import/include
> > mechanism has been sufficient in programming languages
> (java, c#, c++,
> > etc.). Java for example does not require imports for stuff
> in the same
> > package (namespace) - however, the location is implied in
> that case ..
> > so the analogy isn't exact. My personal preference would be
> to use one
> > construct with location requiredness defined in terms of namespace
> > sameness, but the XSD experience seems to have some reasons for not 
> > going that way.
> 
> Gudge, would you be able to tell us (me) why XSD chose to use
> two language constructs instead of one for the include/import problem?
> 
> Thanks,
> 
> Sanjiva.
> 
> 
>

Received on Monday, 14 October 2002 23:54:00 UTC