Re: import/include

Hi Gudge,

Wow, thanks for the very detailed and clear explanation!

I am now even more convinced that we should just have one thing
instead of two. As your explanation noted we don't really have
a technical reason for having two syntactic constructs for the
same namespace vs. different namespace re-use scenarios. I don't
particularly care about the validation concerns because the XSD
of the language will likely end up being more flexibile than
legally allowed anyway and we'll have to have lots of annotations
to clarify the actually allowed concepts. In any case, I don't
believe we should design WSDL (or any language for that matter)
based on what XSD can or cannot do. Of course, to whatever
extent possible we should absolutely be XSD-friendly.

In summary, I'd like to go with <import> only without a separate
<include> element. If there's a lot of concern about potential
user-confusion because of the similarity-but-not with <xsd:import>
may be we could consider another word. Doesn't C# use "using"
for the what Java uses "import" for? I would be happy with:
    <using namespace="uri" location="url"/>

Thanks again for the detailed explanation below ..

Sanjiva.

----- Original Message -----
From: "Martin Gudgin" <mgudgin@microsoft.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>; "WS-Desc WG (Public)"
<www-ws-desc@w3.org>
Sent: Tuesday, October 15, 2002 9:53 AM
Subject: 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 Thursday, 24 October 2002 00:48:34 UTC