RE: Just what is a Core Component? Or, when is stealing wrong?

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

I second the motion (to mine ebXML elements from EDIFACT).

Disucssion:

I picture a class hierarchy in which:
	A) All XML elements used in ebXML messages derive from a single base
ebXML class
	B) This base ebXML class has two subclasses, composites and
primitives.
		1) Composites are collections of other ebXML elements
		2) Primitive are elements which carry value instances

Additional subclasses may be derived from the composite and primitive
classes.

Seems like the CC group have spent way too much effort worrying about
composites (especially the more complex composites), and have spent way too
little effort worrying about primitives, which in the final analysis carry
the data that fits between the delimiters of an EDIFACT document (the raw
information we're trying to convey).

As William notes, the EDIFACT dictionary contains a wealth of knowledge
about primitives.  This is especially true if one insists that an ebXML
element act as a reasonably complete semantic container for a data value.
That is, information that contributes to the semantic understanding of an
element should be conveyed as properties of the primitive element.  Looking
at the use of elemnts in EDIFACT, one popular primitive <template> might be:

    <someGenericElement ID='someSemanticEnhancementIdentifierCode'
v='someValue'/>

from which we might derive:

	<quantity ID='...' v='.../> 

Note that this singe XML element encompasses two related EDIFACT elements, a
'qualifier' element and a 'value' element.  

One might also note that some (many?) elements in EDIFACT have quite
descriptive element names, and so might not need an ID qualifier to provide
a reasonable semantic understanding of the information being conveyed.  

Also, one might find that some semantically equivalent elements are
represented in the dictionary both in qualified generic form and in
descriptive element form.  Hence, there might be a <quantity ID='[Sold]'
v='...'/> and a <quantitySold v='...'/>  Use of the latter form where
message semantics has restricted the kind of quantity that is conveyed to a
single choice is standard practice in EDIFACT message design.  Technically,
the two elements represent the same semantics, and the more descriptive
element is in a subset class of the more generic element.

I highly recommend that an effort be undertaken to extract ebXML
'primitives' from the EDIFACT dictionary. That's a simpler task than trying
to define complex environment sensitive core components like PartyID.  And
by all means, let's keep excellent documentation as to the source of the
derivitions of PC's (Primitive Components), as that will ease ebXML/EDIFACT
interoperability issues.

Cheers,
        Bob


-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: Monday, April 23, 2001 3:02 PM
To: ebXML Core
Subject: Re: Just what is a Core Component? Or, when is stealing wrong?


David Welsh writes: "Nothing like short emails. Thank goodness we're not
dealing with mathematical equations!"

I assume David was referring to my last posting, because all 900 words
of it tailed his short comments.

Reading my contribution should take but a few minutes.  Hopefully, it
was sufficient to prove the CC catalog is nothing but a simulacrum of
EDIFACT snippets.  And as such, my modest proposal - all the way at the
end of six (!!!) paragraphs - entails nothing but the suggestion that we
(i.e, someone other than myself) simply model EDIFACT as the source of
core components.

This will have the gratifying effect of eliminating interminable Core
Component meetings, which, fortunately,  I have not spent hours - nay,
weeks - of my life attending.  This is not to say I don't want to spend
weeks of my life in various exotic pleasure spots, like Brussels and
Vienna.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"accelerating time-to-trade"




------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org