OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Tod,

   Codes are a shortened representation of something

   e.g US - for the united states, M for male

    ID - is a piece of data that uniquely identifies a particular instance
of something or someone .

     e.g U167166111B - to identify a particular container
           on a ship
          or MM-123-666 to identify a box by its mark or number.

      An ID can be fairly abitrary, and transitory where as a code within a
a particular list is unique,  unchangeable universal.

my 2ps worth

Cheers, Phil




----- Original Message -----
From: "Todd Boyle" <tboyle@rosehill.net>
To: "Thomas Y.T. Lee" <ytlee@csis.hku.hk>;
<ubl-comment@lists.oasis-open.org>
Sent: Sunday, June 30, 2002 8:15 PM
Subject: Re: [ubl-comment] To define propietary business documents


> 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=AmericanPsychiatricAssociationDiagnosticStati
sticalManualOfMentalDisorders
>
> 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.
>
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC