Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c2ahli$opr$1_at_news.netins.net...
> OK, maybe I'll have to devise one of my own since there is a fairly
> well-defined and not very profound picture of what a service is in my
> thinking. Here's a first attempt:
>
> A service is a function with the following properties:
>
> 1) It implements a "published" interface and is registered with a lookup
> service (such as UDDI UBR or a Jini LUS). There is a subset of all human
> beings and/or software with access to look up the specification of what
the
> function takes as input, what it gives as output and what processing it
> does.

This makes sense, but begs several questions: 1. What does "published" mean? There must be a standard definition of a lookup service. That implies an agreed-upon protocol, both for basic transmission and for message formats. It seems this question chases its tail a bit... there needs to be at least one agreed-upon service, to find the others ("one service to bind them all...").

2. How do you define "what processing it does"? Describing the semantics of operations is difficult, and requires a declarative language not easily crammed into XML. It's hard enough to define what the input and output "mean."

> 2) A client using the service must specify the name of the function, where
> to find it, and how to launch it (information it might get electronically
> from the lookup service) along with input parameters but does not provide
> the service with a run-time environment wherein to launch.

In other words, the service is invoked without knowing its location. But does that include a URL - surely SOAP and other protocols have to know that?

> Is that any clearer, Eric? I suspect not, so I'll work on it more in the
> future.

It's definitely clearer than those others' definitions.

> > > I think of everything as functions and everything as objects.
> >
> > There's a fundamental conflict there.
>
> No, there really isn't. The relations I care about are there with a key
so
> they can be thought of as functions, such as Person("12345")=("Mary",
"Fox",
> "4/6/56", "brown")

This confuses relations and types, but that's a different story discussed in Third Manifesto and Intro-DB Systems.

> You can likely see that one direction is easy -- all functions are
objects.
> They are objects of the type "function".

I don't see that at all. Functional programming and object-oriented programming are very different. Functions in themselves don't allow inheritance (though there's polymorphism and subtyping, in languages that can handle function types). Languages like Java don't allow functions to be referenced directly. In what sense are functions objects?

I think this implies an extremely fuzzy (i.e. useless) definition of "object".

> The other direction is really
> based on the fact that computers need handles of some sort to find things.
> So, objects can be seen in terms of object is identical to seeing
> function(reference-id)=entity or function(simple-value)=entity. for
> example, the object that is the google home page could be represented as a
> single point in a broader WebDocumet function so that
> WebDocument(www.google.com)= ... (put page here).

Yes, but not all queries are so simplistic. Relational queries allow you to specify natural criteria, and aren't hinging on pointers, OIDs and the like.

> We could make this a function specific only to this object if we wanted
to,
> by narrowing down the domain of the function to just www.google.com --
this
> would only be done in order to be able to say that all objects are
functions
> and all functions are objects. You take an object as input to a function
> and return another object, recognizing these objects are, themselves,
> functions.

Uh... I don't see what all this is going.

> > However, in a relational context, why not just have the RDBMS expose
this
> > service as a relation? Then it could be clearly specified what the
> > "relationship" is between the results of that service and your other
data.
> > You're still specifying the equivalent of a foreign key constraint - you
> > don't want data with an invalid country going in there, do you? I think
> what
> > you're describing is more implementation - we're getting the data from
> > elsewhere, rather than storing it in a base relation.
>
> I think of it more as getting the service from whereever and that service
> could be one that validates data entered into a system, or data that is
> requesting storage in a repository or whatever. Where that service gets
any
> data it needs other than the input parameters is irrelevant.

Modeling that capability as a service is inferior to modeling it as a relation, because the service requires explicit invocation. A relation, and constraints, just are. The service paradigm breaks down because there's no declaration of basic prerequisites, orderings, etc., which would be required for function call semantics to be meaningful for data validation. In short, functions are there to be called if you feel like it. I think real applications need something better.

> > I think it adds more complexity than you think. Properly factoring
> services,
> > and even invocations of remote services, can get very hairy in a
> > moderately-complex application. I've seen it sink several projects. It's
> > actually far more difficult than designing a normalized set of
relations,
> > because there are fewer solid guidelines on which to build. For example,
> the
> > "types" of the function calls become a major problem, unless of course
you
> > do what so many others do: make 'em all Strings.
>
> That is my preference (all strings) but that is based more on experience
> than theory because I would like to control the response to the service
> client.

Generic strings are even more evil than XML. They're as useless as byte arrays. They say nothing useful, and require coordination between client and server. They place all the burden on developers, and allow no programmatic help whatsoever. Another step backward...

> > I will give XML one thing: it has gotten groups of companies talking
about
> > their data and what it means. I regret, though, that it provides such a
> > crippled format in which to express those meanings.
>
> I think of it as verbose -- where it is crippled compared to comma-quote
or
> card column data transmissions that have occured historically?

It's no more crippled than those formats, and in fact XML Schema (and even DTDs) allow more. But there are much richer data definition capabilities... relational (e.g. Tutorial D), for one.

> > Validation would depend on a common agreement on "type." And there is
much
> > more to type than what XML can express.
>
> or that anything can express, including English. Having a service that is
> agreed upon as a means to validate a particular data element does not
> eliminate such discussions between people on what the data really are.

More can be said via relational languages, programatically. In other words, the internal predicates can be stated clearly and made available (as relations) for any program, for code generation etc. Coordination with external predicates ("business meaning") is always a human task.

> I'll check out Alloy, but I guess I'm not a believer right now, although I
> have been in the past. Maybe I'm a prodigal son who will return to
> preaching the merits of the relational model, but I'm finding more
benefits
> in other approaches right now (such as modeling data as graphs, di-graphs,
> trees, and other functions).

Keep in mind that modeling data as functions requires some relationships between those functions (e.g. a full algebra).

> OK, I'll buy that given this thread is about not having multiple specs --
> but then those database services need to be usable by clients with a
greater
> diversity of needs. For example, clients that need to toss a combo box on
a
> screen (or even though that need to know what to toss up on the screen).

I don't think those needs are more diverse - in fact, I think what the UI needs would be completely implied by the constraints, domains, and relations. Except for screen position and such, which is simple to encode elsewhere (even as relations!).

> I know I'm still giving muddy answers. I'll keep trying to put words to
> thoughts. Thanks. --dawn

No problem... I'm sure mine are murky too, but I enjoy the discussion.

• Eric