[
Lists Home |
Date Index |
Thread Index
]
- From: Uche Ogbuji <uche.ogbuji@fourthought.com>
- To: Jonathan Borden <jborden@mediaone.net>
- Date: Mon, 18 Dec 2000 09:36:41 -0700 (MST)
> Please don't equate the term "provide constraints" to a stating that
> schemata are *restricted* to a set of constraints.
>
> A schema has two broad functions:
>
> 1) contraints
> 2) transforms (e.g. attribute defaulting)
Hmm. Reading yours and Rick's messages, I'm beginning to wonder whether
I'm not putting too classical a construction on the term "schema".
In my opinion, and my analysis so far, the two functions of a schema are
1) constraints
2) processing plan
Where your "2) transforms" are a subset of my "2) processing plan".
I think a schema can be an overall guide to how the data is to be viewed,
queried, modified. SQL schemas provide precedent for this in computer science.
Again, we might actually be in agreement, but not all roles of processing
plan I can think of are limited to transforms.
> Yet formally one might consider all constraints a type of transform, one
> that returns either 'true' or 'false' depending on the input. In any case it
> remains useful to consider schemata as providing constraints.
Oh, you sly fox. A very neat way to put the matter aside. Everything is
a function. The only problem is that I think for this discussion some of
the confusion comes from exactly what do we expect from the function we
call a "schema". On the one hand you suggest true/false. On another you
suggest a transformed tree or graph. I'm suggesting perhaps a turing
machine. No wonder the discussion is all over the place: the curse of the
S-word.
I certainly agree with Eric that the answer should be "all of the above".
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
|
