Too many moving parts: Re: meta-specs

[Jonathan Borden <jborden@mediaone.net>]

Len,

> I am curious about various approaches that tie it all together
> and in this particular case, wondering if for some time period
> it may be wise to focus on the instances and therefore, XML
> Schemas as a simple means to get definitions for instances.

> In total there would be many modules, but to begin with, having
> chosen some categories of information, we sort out membership
> of various documents and record that sorting in the document
> type (schema).  It takes a "feel" for the data domains followed
> by normalization, then iterate until it *feels right*.
>
> Is that too... Extreme?

:-) The question is how to best capture this schema as a collection.

Whatever works. You might write a Schematron and keep adding assertions
until all the instances you want in are in and all the instances you want
out are out.

>
> I understand that you are looking at a type system
> independent of the schema language.  I need to understand
> that better.  My dilemma is "too many moving parts", that
> is, having so many ways to design that it becomes difficult
> to choose.  Schemas I know so I tend toward what I know and
> that isn't always the best metric.

Sure. What I would like to ultimately see is for people to use whatever
tools or languages feel best for their task. We get back into the software
project composed of multiple modules in multiple languages trying to work
together. So objects were invented as a way to abstract a module based on
its properties and methods. In the same way that a bunch of code becomes a
"method" and a data structure becomes a "property", a schema module or a
constraint or an XPath becomes a type (each defines a set of instances).
Types as sets of nodes abstracts the concept of "type" from the particular
language used to express the constraints on the set.

Perhaps we will ultimately be able to validate a document which contains
several vocabularies in different namespaces and each vocabulary is
described using a different language. This meta-schema validator just asks
each node: are you ok? and the node is responsible for figuring out if it
and what it contains is ok. If everything is ok the document is valid.

The problem with too many moving parts, is not that there are too many
parts, or that they are moving, but that they are moving in different
directions without regard for eachother. With a few screws and some oil
perhaps we can assemble a bunch of spinning cogwheels into a swiss watch.


>
> I like your approach in that it appeals to my need to start
> as much as possible from simple devices.  If we have the
> instances nailed down, we have a pretty good idea how to
> then begin to look at different schemata techniques and
> thus, which one best models some particular kinds of
> constraints because we know what the outputs look like.
> If we got the categories right, we are in the right
> neighborhood.  So I am following this with great interest.
>
> I realize how unscientific it all sounds, but after
> some years of doing this, I am convinced schema design
> is art supported by method. :-)

It _is_ scientific :-) The "Schema Algebra" is just a fancy formal way of
stating the same. The only reason this needs to be said in a mathematical
way is that we need to be very precise about what we are doing. Precision
can be simple.

-Jonathan