Standards that (might) matter

[Todd Boyle]

I agree with Christopher's point that it has *not* been very useful for
developers to observe standards for GLs or other internal business
systems, up to the present.  Standards such as SQL which are
useful are of course, being used.

If I were going to point at the most relevant standards to observe
today, I would not have included CORBA or the GL or ARAP projects,
even though I am a member of the ARAP project.   I would have
recommended

1. the Core Components specification of UN/CEFACT which intends
to provide a metadata framework for all of e-business, and is regarded
by many as the vocabulary framework for web services as well as
the next generation of EDI,
http://www.unece.org/cefact/ebxml/ebXML_CCTS_Part1_V1-8.pdf
http://ebtwg.org/projects/
http://lists.ebtwg.org/archives/ebtwg-ccs/

  and

2. The UBL (uniform business language) which is a bunch of very hard
working people headed by Jon Bosak and others, trying to produce the
common, horizontal vocabulary faster and better than UN/CEFACT.
They are starting with the xCBL 3.0 vocabulary from Commerce One.
http://www.oasis-open.org/committees/ubl/

Vocabulary standards are one of the keys to machine conversations
over the internet.  I appreciate that technical interfaces matter!  But
we already have SOAP interfaces, XML/RPC or whatever.  The critical
missing piece has always been, "What does this data mean!"   Normative,
global data dictionaries are a whole, new thing that everybody will
benefit from.  These include aggregates of data elements as well as
whole documents like purchase orders.

We are on the early edge of a very big change.  One of the differences
between these standards and past standards such as EDI is that
they are 'syntax neutral'.  You can use XML, ASCII like EDI, or anything
else that's appropriate in your space.  The vocabulary efforts are
at a higher level of abstraction--defining unique conceptual entities.
Each conceptual definition has actually got two unique identifiers:
a 6-digit number and a unique Dictionary Entry Name.

Therefore, using those conceptual definitions rather ensures that
your interface can communicate globally, i.e. it can be mapped.
Of course, it can be mapped whether you do anything today, or
not.  So, not to worry.  The real question is whether your application
logic even gives a damn about talking with the outside, and how
well adapted is your business logic to support any conversations
with an untrusted global public?   All trading partners are adverse
parties.  This is different from an entirely internal system.

TOdd
Todd Boyle CPA  9745-128th Ave NE  Kirkland WA
International Accounting Services, LLC  www.gldialtone.com
address@hidden  425-827-3107  project www.arapxml.net


At 10:37 AM 3/4/02, Christopher Browne wrote:
somebody had said,
> > >Technology is changing so qickly, so by the time the standards are
> > produced they become outdated.
> >
> > Yet, basic accounting doesn't.  Creative ENRON account will change however
> > :-)
> >
> > >For example I see SQL-ledger.org going in this direction very quickly.
> >
> > Mr. Simader has not been following the standards issues to date.
> > I am not sure if he wants to implement whatever he thinks of, or what
> > the standard(s) say should be implemented.
>
> The two "standards" I'm aware of that would _arguably_ be relevant to
> SQL-Ledger would be:
>   a) The CORBA interfaces for G/L and AR/AP;
>   b) Standardized output schemes where financial reports are generated
>      in a particular form of XML.
>
> SQL-Ledger has ignored both, and I frankly see little reason for 
> developers to
> concern themselves with these things when they're not being at all widely 
> used
> to provide any interoperability.
>
> > Correct implementations of standards allows for interoperation.  Thus, 
> say
> > an XML based report generation software could chat with a totally 
> different GL
> > sub-system.   (a rising tide floats all boats)
>
> The thing is, the amount of infrastructure needed to build such
> "meta-communications systems" inserts a big whack of complexity.
>
> It's not obvious that introducing this complexity actually provides a "return
> on investment" by providing _substantially_ increased functionality.
>
> It would be pretty neat if one were to build a payroll system that would 
> speak
> (via CORBA, or perhaps via a SOAP interface using the same sorts of interface
> functions) to SQL-Ledger as well as to some other packages.
>
> But it's not evident that you actually win very much from this.  Adding the
> interfaces as well as separate technologies means that the system gets more
> complex.
>
> If we built a payroll module for SQL-Ledger (which I actually have put some
> effort into :-) ), that leverages the existing Perl code, the existing DBMS,
> the existing web server, and the existing user interface.
>
> In contrast, if we built SQL-Payroll, a package using:
>  - MySQL
>  - PHP4 embedded into Apache
>  - CORBA interface
>
> This requires throwing in about 4 extra "technologies," which makes the 
> result
> more complex and more fragile, and it probably takes more effort to implement
> it to boot.
>
> I don't think that would be AT ALL an improvement.
>
> To argue the value of standardisation requires that there actually be some
> demonstrable and valuable benefits provided.  So far, I don't see any 
> "value,"
> merely suggestions that it would be a "good idea."  And that's not good 
> enough
> reason.
> --
> (reverse (concatenate 'string "gro.gultn@" "enworbbc"))
> http://www.ntlug.org/~cbbrowne/emacs.html
> "...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
> the Ugly)."  -- Matt Welsh
>
>
>
> _______________________________________________
> Gnue mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue