Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
