[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Standards that (might) matter
Standards that (might) matter
Mon, 04 Mar 2002 12:43:52 -0800
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
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,
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.
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 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
concern themselves with these things when they're not being at all widely
to provide any interoperability.
> Correct implementations of standards allows for interoperation. Thus,
> an XML based report generation software could chat with a totally
> 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
(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
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:
- PHP4 embedded into Apache
- CORBA interface
This requires throwing in about 4 extra "technologies," which makes the
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
merely suggestions that it would be a "good idea." And that's not good
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly)." -- Matt Welsh
Gnue mailing list