RE: Data Dictionary Concept

[Jeff Childers]

Todd,

I looked over the links you provided (thanks). Good stuff, if a little
heady.

Personally, I am 100% in favor of building an open-standards platform to
drive e-transactions. I share your frustration with the inefficiency of what
is largely a 1,000-year-old process, not to mention that I have written
several EDIX12 packages and would be happy if I never heard of that
"standard" again.

Two items of note:
1) If GNUe is ready for the standards, are the standards ready for GNUe? It
sems like much of this work is still in process. 
2) We have yet to hear from Derek or anyone else on the GNUe project about
the data dictionary. Given that this project has a depth of history behind
it already, key decisions may have already been made.  

Next, I think encapsulating additional information at the types level and/or
the metadata level could still achieve what I suggest regardless of whether
the Oasis registry object or any other metadata controller were used. PS -
I'm not familiar with the Oasis language so forgive me if my description is
inaccurate.

The ebXML may offer as much time savings in providing an industry-acceptable
format as it requires in additional ramp-up. One does wonder, though, with
all the new acronyms these days, just how many standards one project can
support.

Regards, 

Jeff



-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of Todd
Boyle
Sent: Sunday, August 18, 2002 2:25 PM
To: J. Childers; address@hidden
Subject: Re: Data Dictionary Concept


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,
   and
  - 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
http://www.oasis-open.org/committees/regrep/

Open source RegRep project
http://sourceforge.net/projects/ebxmlrr

The ebXML core component specification
http://www.ebtwg.org/projects/core.html

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,

Todd

At 09:00 AM 8/18/2002, J. Childers wrote:
>Derek,
>
>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.
>
>
>Regards,
>
>Jeff Childers
>
>
>-----Original Message-----
>From: address@hidden [mailto:address@hidden Behalf Of Derek
>Neighbors
>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
>address@hidden
>
>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)
>
>-Derek
>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
> > http://www.hotjobs.com
> >
> >
> > _______________________________________________
> > Gnue mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/gnue
> >
>
>
>
>
>_______________________________________________
>Gnue mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/gnue
>
>
>__________________________________________________
>Do You Yahoo!?
>HotJobs - Search Thousands of New Jobs
>http://www.hotjobs.com
>
>
>_______________________________________________
>Gnue mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/gnue



_______________________________________________
Gnue mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gnue