RE: Schemas and Semantics (was: A Personal Reply...)

["David E. Cleary" <davec@progress.com>]

> b) Definitely the underlying schema model should be extremely generic and
> independent of any concrete syntax. The lack of such a model in
> XSD is very
> disturbing. Perhaps this is the crux of people's objections to
> putting vital
> semantics into schemas.

XSD isn't tied to its transfer syntax. In fact, there may be cases where XSD
components can not be represented by the transfer syntax, although I know of
none. Also, for those mathemeticians out there, MSL provides a normative
mathematical model of XSD. So I'm not sure exactly what your complaint is.

> Equally disturbing is the lack of a decoupled
> extensibility mechanism like Tibco's Schema Adjunct Framework.
> Sure we have
> "appinfo", but embedding this metadata directly in the schema is
> another big
> problem because the schema has to be modified for each
> application that uses
> its own types of semantics.

How would you associate an adjunct with a schema without editing the schema?
Also, what is wrong with modifying a schema with application semantics? I
know the systems I work with will not be retrieving remote copies of schema
to do validation because of availability and trust issues. They will use
local copies.

> The underlying semantics will always be the
> same, but a database application clearly needs different metadata from a
> Bean generator. The fact there isn't a built-in mechanism for associating
> multiple files containing schema-level metadata with a schema is a big
> mistake responsible for much of the bloat in the spec. Would this kind of
> approach alleviate people's objections to using schemas as the underlying
> model for XML-based software architectures?

I disagree that the bloat in schema is due to this. First, XSD supports
generating a schema based on multiple schemas. Second, XSD validation rules
support validating an instance against multiple schemas that may have no
connection with each other whatsoever. Can you give an example of the kind
of metadata that is narowly focused and causes bloat in the spec?

David Cleary
Progress Software