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

I had a question Umit about a statement you made this morning on this
subject, that we should not do any inlining of schemas, relying always
on importing an external schema, because that would help us use Schema
monolithically instead of retrofitting changes into the Schema spec.  At
least that's what I heard :-).

I don't think this is accurate.  As far as I can find, Schema doesn't
operate differently just because the <xs:schema> element appears as a
root element.  There isn't a difference between creating a set of
components from two imported schemas instead of two inlined schemas.  We
require a targetNamespace on both imported and inlined schemas, which is
I think the only restriction we place on Schema instances.

Replacing imported schemas with an inlined version has only one effect I
can find: the disappearance of the schemaLocation hint.  When
<xs:import> is used, the system locates a schema through some magic,
which may involve use of the schemaLocation attribute.  We don't
constrain this in any way. A processor is free to simply say "I can't
find a corresponding schema" and fail any processing that requires
components from that schema.  The implication of an inlined schema is
that the components defined therein are much more likely to be
available, since there is no reliance on a schema location mechanism to
locate the schema.

What the spec doesn't say, is whether inlined schemas are actually
guaranteed to be available.  That is, the schema components in the
WSDL+Schema component model must include at least those components
defined in inline schemas, along with any components from imported
schemas found by a schema location mechanism (which may be none).  Add
of course the caveat that any processing that relies on a component that
is not present will fail.

I'm not sure whether this implied difference between imported and
inlined schemas should be enhanced, or reduced.

Received on Thursday, 23 October 2003 14:45:30 UTC