Re: Data Dictionary, Draft 2

[Paul Robinson]

> If you have previous experience in this sort of endeavour Paul, that's
too
> great an opportunity to pass up. Will you act as a filter on this
stuff
for
> us? Interested in taking part?
>
> Ian.
I am interested in taking part. Although I'm flying out to New York
tomorrow
for a couple of weeks on business. On return to heathrow I'm having a taxi
take me straight to High Wycombe for the cbus course. That's gonna be a
long
day!

Anyway, I won't be able to do much over the next couple of weeks, but would
be happy to get involved after that. I've no experience of the schemas or
code behind xpl - that can be both good and bad IYSWIM.

I've written lots of assembler (long time ago), C and Java. For the last 7
years I've been involved in finance software, and that's where we ran into
the dictionary problems. I still think the basic idea was good for that
project, it was just that some people on the team pushed the idea too far.
With the possibility of things getting horribly complex, the best approach
(as ever) is to keep it simple.

> In particular, the suggestion Keith just made.. INPUT and SOURCE seem
to
me
> pretty similar, I'm bowing to greater knowledge on that one...

> the general principle will be that *every* zone like operation,
whether
> that's IR, heating, lighting, *anything* will use ZONE. having the
ZONE
and
> ZONENAME gives a great degree of flexibility,
In principle, that sounds fine. In practice, it won't work for everything.
For example, when splitting things into zones, you will probably find that
different applications will require a different set of zones. That may then
get furtehr complicated by some application that handles two different sets
of zones. A simple example might be controlling lights by PIRs. You may
split your PIRs into zones, and then split your lights into a completely
different set of zones. There would then be a temptation for such an
application to use PIRZONE and LIGHTZONE etc. This is what I mean by having
things that are the same, but different. In this particular example, you'd
probably fix it by having an attribute inside ZONE that specified the type
of zone - PIR or LIGHT. However, you can see the problem.

The INPUT and SOURCE problem is slightly different. For each application,
what is essentially the same thing may find it natural to use different
words. In general, it would be better if applications could agree to use
the
existing word. In practice, it's not possible. In Keith's case, SOURCE may
mean "the original root kat5 source" rather than "the thing
upstream that
feeds me". The difference being that some equipment will receive a
kat5 feed
and then pass it on downstream. Is the source for the downstream equipment
the kit in the middle or the root source? The word "source" means
more in
this case than Keith would probably want it to and "input" makes
much more
sense because it has fewer connotations.

Some applications won't need to distinguish these sort of subtleties. Some
applications will be created in future which will need to add some subtle
qualification or change to stuff that already exists and seems (now) to be
trivial. You may have thought that about SOURCE.

These sort of issues feel like they should be simple, but I don't think
they
are. This is one case where the little things add up to big things. While I
don't want to sound too negative, this is one area where we really need to
be careful because it could end up adversely affecting the simplicity of
xpl
and the ability to have an application that can make sense of messages from
new applications.

Paul