RE: Can one inline schema import definitions from a second inline schema?

Umit, I didn't find an easy way to respond to your message, so please
allow me to start fresh.

I think you are arguing that we should only allow imported schemas (e.g.
only allow xs:import inside <types> instead of <xs:schema> and
<xs:import>).  If you are not proposing that we disallow inlined schemas
(<types><xs:schema/></types>) then I apologize and you can stop reading
now!  If this is your position, then read on.


First Assumption: XML Schema itself does not distinguish between the
processing of <xs:schema> elements appearing as a document root or
inside another element.  That is, the same components are built by the
schema processor in both cases.  I think we agree on that.


Second Assumption: <xs:import> serves two purposes.

First, it declares a namespace for use by QName references within the
schema.  This can be checked at the syntactic level, and any references
to QNames not imported can be flagged as errors.  In WSDL, we say that
QName references to schema-defined QNames must come from either the
targetNamespace of an inlined schema, or a namespace indicated by an
import.  Again, this is syntactically checkable, and consistent with
schema.  This WSDL mechanism does not impose any constraints on a schema
processor.  Therefore there is no functional difference between an
inlined schema and an imported schema in this area.

Second, the <xs:import> signals that schema definitions are not
specified locally, but must be located by the environment using
mechanisms enabled but not constrained by the schema specification.
<xs:import location=""/> is merely a hint that may help in this
environment-specific activity.


So, the obvious difference between and imported schema and an inlined
one is the "location" attribute which appears on <xs:import> but not on
<types><xs:schema/></types>.  The lack of this attribute implies that
the mechanism for locating schema components is different.  The process
by which <xs:schema> elements are processed is not different, only the
way those elements are found by the consuming application (WSDL
processor, in our case).  If we wish to restrict inlined schemas, it
needs to be justified on the grounds that it simplifies the machinery
that finds schemas, not on the schema processor itself.

The issue I raise is about the interaction of the schema-location
mechanism with inlined schemas.  I assume (it's not clear from the spec)
that the desired behavior is for schema components from inlined schemas
to be actually built from the XML schema syntax inlined.  But I don't
think we say this.  The analogue for <xs;import> would be to say that
the "location" attribute must be processed in a particular way (e.g.
dereferenced to an XML document with <xs:schema> root).  Since we don't
constrain that case, it makes me wonder whether we have explicitly
constrained the inlined case.  For example, if I see <xs:schema
targetNamespace="myns">, and my environment has a set of pre-build
schema components for the myns namespace, do I actually have to parse
the inline schema?

I can see benefits in either converging inlined and imported schemas in
this case, or in differentiating them to provide additional behavior.

Hope this is clearer.

Received on Friday, 24 October 2003 19:48:38 UTC