Paul Downy wrote

> The Chairs' report, published last night, attempts to summarise the
> discussion at the workshop around this very topic, see 'Profiles':
>
> http://www.w3.org/2005/06/21-schema-workshop/chairs-report.html

"There appeared to be no obvious way to split the XML Schema specification
into layers or sub-languages"

So XML Schemas is such spaghetti that it cannot be untangled? Yikes.
But I don't believe it.

From the structures spec, in order,

1) Remove keyref/uniqueness to a new part
2) Remove runtime discovery (xsi:type, xsi:nil, xsi:schemaLocation) and
topdown validation to a new part
3) Remove static schema component construction and modularity
(import/include/redefine/abstract?) elements to a new part
4) Remove complex type derivation to a new part

This results in a Structures spec similar in scope to DTDs,
which just relates to grammars and attributes, does not
rely on a validation phase, and is not couched in terms
of runtime discovery. This doesn't change XML Schemas, but it
provides a way that incomplete implementations or profiles
can say "we support all of Structures, but we don't do
Runtime discovery and we don't check Keyref."

Two practical results of this refactoring would be
i) XML Schemas would not be tied to an irrelevant processing
model as much.
ii) Developers would know that when they don't support a
core Structure feature (any, mixed content) they really are
treading on a tightrope w.r.t. interop.

One problem with a monolithic spec is that it gives little
guidance about what is core and non-core. Everything is
core. A more layered spec such as I suggest would clarify
that, for example, mixed content is a core feature but xsi:nill
is not.

Cheers
Rick Jelliffe