Re: [ubl-comment] To define propietary business documents

[Todd Boyle <tboyle@rosehill.net>]

At 05:58 AM 6/30/02, Thomas Y.T. Lee wrote:

>2. I still have difficutlies in applying the UBL/CC methology, for example
>the use of Id and Code types. (Should IMO Hazard Class use Id or Code? In
>the 0p64 spreadsheet, Id is used.)

In my humble opinion, there is *no difference* between an ID and a Code.
In fact these both resemble nothing but a function, in which you stuff
a value into a black box, and it returns something back to you.  That
principle has been build a million times, in a million different ways.

I've never heard any convincing story why Code/ID are different.  I
think the reason UN/CEFACT is so conflicted over such a thing, what's
really going on is they're trying to implement some different political
rules by constraining the functionality of registries about who, and
what organization (Agency) will be Code list agencies versus who will
be allowed to maintain Identifiers.  They both have an index value and
they both return a structure or document not a single value. They
are technically the same thing.   (I might add, the context facility is
similar in codifying a solution for something that is essentially a
political economic problem.  It accommodates diverse/incompatible
aggregates (document schemas) and tries to provide a systematic
way for them to be mapped against each other, afaics that also,
is a technical accomplishment already done a million times by
middleware vendors, and we haven't even provided taxonomies for our
framework.)

Use ID.  Forget about code. Codes are evil.  :-)

Some owners of list data will use the CCTS "Code" type.
When you encounter them you can

  - wrapper them as an Identifier type, or

  - if the set is small or static, in your market or community then, put the
  whole set or subset, in your runtime, or XML schema.  But don't
attempt to put the entire EDIFACT code lists, like
CommerceOne did with their XDR version of XCBL, "XCBL30.xdr"
which is 691Kb.
http://www.google.com/search?q=AmericanPsychiatricAssociationDiagnosticStatisticalManualOfMentalDisorders

The more I look at the basic Types in the CCTS I wonder why they don't
just align them with base types in Java, C, and other lower level
programming languages.  That exercise has already been performed by
a very large technical workgroup who created the XML Schema types.
CC workgroup should have adopted either the Java types, C types,
or XML Schema types (or a subset) at least, as CCTs.

UN/CEFACT is an inappropriate place to try to redefine low
level datatypes and IMO the CCTS workgroup has been unwise,
inventing simpler generalizations of types that are not technically
equivalent to any language's lower level types, and inserting
too many layers into the hierarchy of information.

Again, this is my personal view and does not reflect the current
Core Components Technical Specification, so I could be wrong.
I regret, I have already written my comments to the CCTS in
past cycles and will not be submitting into the ongoing CCTS
effort until the eight layers of the Core Component stack are
consolidated into something simpler. If you're interested in more
discussion, here are some experiences I had in expressing
general-purpose accounting schema in Core Components,
   http://www.gldialtone.com/UseCCsInGLs.htm

Apologies for my opinion, and with warm regards,
Todd
Todd Boyle CPA  9745-128th Ave NE  Kirkland WA
International Accounting Services, LLC  www.gldialtone.com
425-827-3107  AR/AP everywhere  www.arapxml.net
Give me ambiguity or give me something else.