[
Lists Home |
Date Index |
Thread Index
]
David,
I think you grossly misinterpreted my posting below. The concepts in my
posting are actually completely in line with many of the presentations
you have given on this subject, including those very recently.
<Quote1>
standardized names does not increase interoperability
at all.
</Quote1>
That was not explicitly stated nor implicitly implied in my posting
below.
<Quote2>
Add to this the CAM ability to capture the business
semantics associated with the business process and
transaction interchanges - then you have the ability to
understand the information that you are receiving.
</Quote2>
Yes I know.
<Quote3>
Just knowing what the name of a field is does not cut it,
nor does just assuming because its the same name,
that the information is the same. The means behind
how the data got into that field is critical information.
</Quote3>
I think you're preaching to the choir here. ;)
Joe
David RR Webber - XML ebusiness wrote:
>
> Joe,
>
> I hate to say it but this is a modern myth.
>
> Lesson learned from the CALS and other work is that
> standardized names does not increase interoperability
> at all.
>
> The ebXML approach is centered around UIDs that provide
> neutral equivalent (or similar) correspondence, and then
> the core component approach with context.
>
> Add to this the CAM ability to capture the business
> semantics associated with the business process and
> transaction interchanges - then you have the ability to
> understand the information that you are receiving.
>
> Just knowing what the name of a field is does not cut it,
> nor does just assuming because its the same name,
> that the information is the same. The means behind
> how the data got into that field is critical information.
>
> Having standard names for things is more of a
> feel-good factor than anything - that shows that
> due diligence has gone into information collection
> and planning. And in any case - the vaguaries of
> language - soon catch up with you. In a big dictionary
> you find things like:
>
> Invoice.payment.date.deferred
>
> and
>
> Payment.date.settlement.delayed
>
> When do you use one and not the other, and are they
> just the same thing anyway?
>
> Then in payroll systems things like:
>
> Accumulated.YearToDate.Assessed.Tax
>
> If you think two different payroll software systems
> have the same # in it for the identical employee
> grade, level, pay and hours - then you are
> sadly mistaken! If its different by just a few dollars
> I'd say you were doing good. Usually it will be
> different by a significant amount, depending on the
> accounting procedures and reckoning methods
> being used, and especially what accounting
> period determines YearToDate to be.
>
> Good luck ; -)
>
> Details of the CAM work can be found at:
>
> http://www.oasis-open.org/committees/cam
>
> Cheers, DW.
> ==================================================
> Message text written by Chiusano Joseph
> >Bottom line: This will enable distributed authorities (through the
> distributed registries capability of ebXML Registry) to create and
> maintain data element names (through Core Components, and the ISO/IEC
> 11179 standard Part 5) - thus enhancing interoperability.
> <
begin:vcard
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard
|
