OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: meta-specs (was RE: A few things I noticed about w3c's xml-sc hema)

Hi Jonathan:  

I am forwarding this to the Human Markup list.  Sean is on 
that and understands the context of current discussions there. 
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?

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.  

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


Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

-----Original Message-----
From: Jonathan Borden [mailto:jborden@mediaone.net]

I am discussing a type system that is independent of schema languages.

> Then in a data-centric design, I would concentrate on one
> schema language, and more particularly, I would
> concentrate on the instances I wish to produce.

Sure, but the question is in the context of "how do I make sense of these
different systems"?

> Yes?  Or what does it mean to say "instances are equal"?

An "Instance set" is the set of all possible documents which are valid with
respect to a particular schema, for example a specific DTD.

This says that two DTDs dtd-a and dtd-b are "equal" if the set of all
possible documents that are valid with respect to dtd-a is equal to the set
of all possible documents that are valid with respect to dtd-b.

(note that i don't provide a mechanism for actually computing this set, i
don't have too as this is a formal definition).

> In a relational system, it is as if one designed
> the report data, then designed the tables, then designed
> the queries that produce the reports.  Then they
> discover the business rules. Then they create the
> GUI.

Excellent analogy! In SQL, you don't tell the system _how_ to compute the
data, rather you tell the system _what set_ of data you want, and the
implementation (e.g. query engine) does the work.

> Naive yes, but I want an explanation I could give
> to a naive person.  If I have to resort to explaining
> QNames, the explanation is DOA.

Well then don't try to explain XML Schema datatypes, as they are defined by
QNames :-)

Think of a schema as a box with a light on top and a door on the side. The
Instance Set of a Schema is the collection of all the documents for which
the light turns on when you stick the document inside the door of the box.

Now suppose you have 4 of these boxes, all painted black. You are told that
there are two types of Schema boxes, and you are assigned the task of
sorting the schema boxes into two groups.

As you stick each of your documents into the boxes you find that for two of
the boxes, half the documents cause the box to light up and for the other
two boxes the other half of the documents cause the box to light up. You now
have your two groups of documents, and two groups of schemata. We say each
of the schema in the group is "equal" because they each have the same set of
instance documents.