[Top][All Lists]

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

Re: Data Dictionary Concept

From: Todd Boyle
Subject: Re: Data Dictionary Concept
Date: Sun, 18 Aug 2002 11:24:46 -0700

At 09:00 AM 8/18/2002, J. Childers wrote:
>> Has any kind of data dictionary or data structures definition been started yet?

In my opinion. any data dictionary should be based on ebXML
registry/repository and core components specifications, to maximize

 - interoperability of GNUE with other applications in the enterprise,
- interoperability with trading partners in electronic exchanges of information
and collaborative business processes.

One sentence elevator pitch: GNUE is not the only application in
the enterprise, and will need to exchange information with a
huge variety of heterogenous applications and platforms.  GNUE is
an extensive multiuser applicaiton and companies needing GNUE
already have business processes and computers to run them.
It is a minimum requirement then, to run alongside awhile.  During
the implementation/migration phase at the very least, GNUE will
need to integrate with other applications.  And until it is the best
of breed in vertical niches, it will need to support existing software.

The ebXML RegRep specifications

Open source RegRep project

The ebXML core component specification

The IBM/Microsoft UDDI registry was contributed to OASIS
in August.  (OASIS was the community that gave birth to
SGML and now hosts dozens of standards including
most of ebXML)

Patrick Gannon and Karl Best, of OASIS, have committed
publicly from time to time, to harmonizing and aligning
the specifications under OASIS custody.  There

Messages on the UDDI and RegRep mailing lists suggest
that every functionality available in UDDI is available in RegRep.
UDDI does not however, try to accomplish the range of features
in the RegRep, for managing metadata or software objects,

I certainly appreciate how a product-specific data dictionary
gives you ease of use, and immediate payoff and reinforces
your own community, thought processes for your specific product.
To research and adopt the RegRep consumes attention,
away from your own work, your own objects.

The reason I'm posting this is pursuant to the day when
individuals and small businesses can conduct exchanges
with each other (as well as large enterprises) -- That means,
the full range of commitments, fulfillments, and settlements
within some kind of robust framework.  EDI was a framework
that didn't work for Ind's/SME's and we're all paying the price.
Let's make web services or ebXML works for us, in this
lifetime.  There are ten million people in the US doing
nothing but the most mechanical and wasteful administrative
exchanges, aligning business state and dictionary elements
like a big data replication club that generates billions of
errors then employs itself correcting them.  This is truly,
truly sad. If GNUE doesn't help get us away from paper invoices,
printing and mailing checks, etc. I'm gonna scream,


At 09:00 AM 8/18/2002, J. Childers wrote:

Has any kind of data dictionary or data structures definition been started yet? If not, I have a concept that I've been using over the last couple years in our development that seems to really shorten development time. Basically, it works like this (lots of detail left out of course):

Define Possible Properties (think fields in this case) of Objects (think tables) as one of a few
pre-defined types:

1- Primary key (one per object, user-invisible)

2- Surrogate key (user-visible object key e.g. customer, item, vendor "ID" number. All characters
allowed, read/write)

3- Local value ("data"; e.g. units ordered, contact phone no, company name, etc) - list/option values can be set and edited right in data dictionary for combo/list fields this can be a list of values or a SQL statement that returns the list
        - generic data types (char, int, date, logical, etc.)
        - meta-types: e.g. phone number, zip code, currency, etc.

4. Composite value (i.e. "calculated field". The dictionary stores the SQL or object name used to calculate this field at runtime for any time it is used or displayed. Logic in the object class handles calculating the value on the fly whenever the property for this field is accessed from the object. Nothing is actually stored in the table - this is a logical field with no physical counterpart). Examples: line item subtotal, order total, order tax, order freight, A/R account distribution total for invoice, inventory on-hand quantity, etc. So ALL subtotal or aggregated fields are calculated on the fly. It becomes very easy to edit / maintain the calculations at the
data dictionary level, and avoids many data integrity errors.

Now you add default logic to your base classes for data entry controls that determine behavior when the control is created on a form depending on the data type. The only property you are required to set locally is the field ID - the control looks up the typing and other information
from the data dictionary.

TYPE                    BUILT-IN BEHAVIOR
================ ====================================================================
Primary keys    Never shown, only possible behavior is set self to read only)

Surrogate keys Implement lookup logic when in edit mode via right click menu or create a small lookup button next to field on init etc). E.g. Order No control on Invoice form lets you "lookup" the original order form. Customer no control lets you "lookup" the
                        customer card and/or select a different customer.
Implement optional search logic to trigger lookup form/utility.

Local value     Set all properties for control from base data type definition:
E.g. "list" fields get a combo box, "phone no" fields have their input mask set to system default, general validations are set, etc.

Composite value Read only at runtime. However, right click or runtime-level control allows "drill down" to the records that are used to calculate the value. E.g. right-click on AR Debit balance field and see all the individual postings that make up the figure. You can do a lot more
                        with this.

You could define a couple more types (e.g. true "drill-down" and "drill-up" types) but you get the
idea. Here's where the advantages start:

1) The data dictionary becomes the central place where much application behavior and logic can set set or modified (think end-user customizations like the ability to change list values easily).

2) Data dictionary can now be used to enforce core validations at all levels of the application. E.g. you can open the entire table for browsing in a grid -- each individual cell control relies
on the dictionary settings to validate, calculate, format, etc.

3) Adding controls to forms requires only to set the field ID to enable the majority of functionality that you typically want. There could be a single control that even includes the object's caption (from the data dictionary). Designers could just use that single control when building forms and not have to worry about 10 different widgets - the control will self-select the
appropriate widget.

4) Upgrading the base control class can upgrade application-wide behavior.

5) Key modules such as lookup forms, drill-down and drill-up become automated and can be
maintained in a single place.

Detail record entry (e.g. sales order lines) can be easily handled in a grid where each cell is a baseclass control. If the wxPython grid widget isn't working sufficiently well to handle this we
can create our own grid control without enormous effort I think.

What do you think? If you like it, I could flesh it out into something more tangible for peer
review and comment.


Jeff Childers

-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of Derek
Sent: Friday, August 16, 2002 4:25 PM
To: J. Childers
Cc: address@hidden
Subject: Re: Supply Chain Spec Volunteer

Yes we woudl love it, the source of that pdf is in cvs and is actually
in docbook (xml).  You can submit patches to it via address@hidden or

Neil Tiffin was heading up specs, but has other committments now, so
sending to the core will work until we find a new 'head' of application
speficication.  It's really a great job, in fact it even pays well, a
200% increase per day is *GUARANTEED*.  (assuming one is foolish enough
to believe 0*200 = something valuable)

On Thu, 2002-08-15 at 14:22, J. Childers wrote:
> Hey, do you guys want somebody to start fleshing out the SupplyChain.pdf document? I assume that
> it's a spec of sorts...
> I would love to work on that. I have lots of detailed ERP product experience (from coding to
> implementation) and tons of opinions :).  Who's in charge of specs anyway?
> Regards,
> Jeff Childers
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> _______________________________________________
> Gnue mailing list
> address@hidden

Gnue mailing list

Do You Yahoo!?
HotJobs - Search Thousands of New Jobs

Gnue mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]