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

[Matthew Gertner <matthew.gertner@schemantix.com>]

David,

> 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.

If MSL has been officially sanctioned as the formal model for XSD, then this
is a Very Good Thing. I was assuming this wasn't the case, since I couldn't
find a single publicly accessible reference to MSL on the W3C website. My
bad.

> 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.

You give the processing application a pointer to the schema and to the
appropriate adjunct(s). There's nothing inherently wrong with modifying the
schema, but in many cases you wouldn't want to do so. In some cases, the
types of semantics that you want to specify may be broad and better
offloaded in separate adjuncts, rather than all be lumped together in the
schema. This makes the schema more readable and processing more
straightforward and modular. Also, if I'm working with a standard schema, I
don't want to modify it because then I'd have to synchronize when new
versions come out.

> 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?

xsi:null, for one. I'll bravely flout the W3C confidentiality policy and
point out that there was a hugely time-consuming discussion about whether
this should be included in the spec. IMHO this could have been left out and
included in an adjunct, if people need it. This is just one of many, many
examples. I'll happily provide more if you want. Just my opinion but I think
the spec could have been finished much sooner and been much more concise and
accessible if this kind of construct had been left out, with the knowledge
that an SAF-like mechanism is available for those who need to specify
additional metadata.

Regards,
Matthew