MHonArc v2.5.2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ubl-ndrsc] Important eBTWG Code/CCT discussion
Title: Important eBTWG Code/CCT discussion
<<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<[CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: CCSD - DISCUSSION CODE vs IDENTIFIER>> <<CCSD - DISCUSSION CODE vs IDENTIFIER>>
Many of you are not subscribed to the eBTWG CC listserve. The attached messages are from an ongoing discussion of the Core Components Supplementary Documents (CCSD) project team that is also doing a proof of concept for the core components. I think we need to watch their conversations as we may be able to apply some of their thinking with our own as we write our inputs to the CC Technical Specification project team.
Mark
"
--- Begin Message ---
Title: Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER
Hi Todd,
Identifiers seem to be a subclass of codes. The distinction is important in my opinion, which has to to with the maintenance issue (like I mentioned during the call). Like in Edifact, I think that codes need to be maintained and stored with the attribute they are coding: in the repository. Like with BIE's, private lists should (in the name of interoperability) be defined as subsets of the centrally harmonised list.
Identifiers are typically maintained by third parties. The set to identify is mostly (so not in all cases!!) much larger than a set of codes. Here your change request (that was approved) to send (or at least define) the URI of an identification scheme helps.
I think the basic set of types will (and should) not be very dynamic. Types are probably handled on a lower software level and should be fairly stable. There are some types though I am not very comfortable with. One is the DataTime type. First it may be used to define different concepts (point-in-time, period, recurrent period, duration) which is confusing, second because the type contains a "format code" as an attribute that has not been defined. Reference is made to ISO8601, which is a syntax on its own. For the EWG I am preparing a paper on this subject, and I probably will submit a change request to the spec.
Another issue is the "typing" or stereotyping of composites. This is a mechanism now not defined, but probably needed. The discussions in CCSD seem to lead to define ACC's on too low a level (e.g. "Address"), while the level ACC should be the highest non-context dependent. As this is another subject I'll not further elaborate it, but I value your opinion.
Fred
<<< Todd Boyle <tboyle@rosehill.net> 4/10 6:50p >>>
Is Code.Type a specialized case of Identifier.Type?
or,
Are they both specialized cases of something more basic?
or,
neither of the above?
If, upon close inspection, Code and Identifier really are
related classes, either siblings or class/subclass, then,
would there be costs or disruption in changing the CCTS?
In principle, if some change of this nature were found to be
necessary, would CCTS be modified at this time or would it be
wiser to publish an approved version 1.o and push any change
into version 2.x?
Another question one might ask, is whether these two types
(Code and Identifier) are really CCT's. A CCT is supposed to
be an irreducible element, without business context, without
implied behaviors etc. etc. I mean, all of the other CCT's are
almost compuer language datatypes. Let us agree in any case
Code and Identifier types are necessary but, if we found out
that they don't fit the principle then, would pragmatism prevail
over principle? If so then, why not just chuck the principle,
and create a process for the introduction and approval of more
and more CCT's? The CCTS today says that the CCT types
in the CCTS are a closed set. (My own preferences would be
to collapse some of the levels of the "stack" in the CCTS but
I cannot pretend to see the whole big picture.)
I'm just asking; I just think discussion and repetition of some
of these things can be helpful,
Todd
--- End Message ---
--- Begin Message ---
Title: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER
Hi Gait,
I fully agree with you. In the call I said that *mostly* codes are assigned centrally (and immediately noticed that that word is very dangerous in definitions).
You perfectly narrowed down the discussion to the difference between *things* (objects? classes?) and attributes (properties?). So: can an attribute or property be an object itself? Probably it can. Is a "payment terms code" the identification of an object? If "payment terms date" is an attribute, "payment terms" should be an object, or not?
Please advise us, like Melany said, how to make the definitions (more) unambiguous.
Fred
<<< Gait Boxman <gait.boxman@tie.nl> 4/ 9 8:50a >>>
Hi Melanie, Fred, others,
just my 0.02EUR on Codes and Identifiers:
I don't believe that it matters whether the owner of a code or identifier is
a standards org or just a party. It's perfectly viable to have party
specific codelists (or should we say partner-agreed specific codelists), and
it's also quite ok to have standards org assigned id's. An example of the
latter is the UN/LOCODE, or the EAN/UCC party number. In fashion retail,
parties quite often keep their own colour tables, and require translation
between them.
The major distinguishing property of identifiers and codes is that an
identifier tells you WHICH thing in a set of similar things you're talking
about (e.g. which party, which order, which article), while a code
identifies an attribute value that tells you WHAT KIND OF a thing it is
(e.g. the role of a party, the type of an order, or the colour of an
article).
This is already reflected in the existing definitions, which link the codes
to attribute values and identifiers to object identification.
Regards,
Gait Boxman.