RE: where the qualifiers went...

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

Good People,

The hanging question is when are we going to have a sound UML model for
defining Core Components?

It is difficult (and I believe counter-productive) to 'define' a core
component (e.g., 'amount') when we haven't first defined and agreed upon a
UML model. 

I would hope that the model that is developed would not support as a Core
Component 'totalAmountInDollars' or 'shipToParty'.  I would want the UML
model to support 'Amount' in an 'atomic' manner such that the properties
required to produce a 'whole/usable' semantic entity were an integral part
of the definition of Amount.  For 'amount', that would include a semantic
definition (or to my preference, a pointer to a body of XML containing the
definition in some standardized form); a data type (and by association to
the data type class, a set of properties linked to that class, such as range
limits); a currency designation (or a means to derive same from elsewhere in
the document or schema); a semantic constraint (e.g., some (super/)subset of
the ASC X12 DE 522 Amount Qualifier Code list.  NOTE: The ASC X12 Amount
Qualifier Code List is incomplete, because many segments which contain an
'Amount' DE use a semantic note in the segemnt definition to provide the
semantic constraint to a single constraint value (e.g., to represent 'Net'
amount).)  
  
How an 'amount' is represented in a particular syntax must not be a factor
in defining 'amount' as a Core Component. 

I am perfectly comfortable with having multiple physical representations of
an 'amount' in X12 syntax, in XML syntax, in EDIFACT syntax.
That X12 chooses to use semantic notes in some cases to constrain semantic
meaning, or perhaps uses a composite to relate the properties of an amount
is not a problem to me.  That one might define both an 'amount' XML element
having fixed or variable attributes to specify properties, or having
pointers to other elements which convey those same properties is not a
problem to me.  Defining a document in which there is no documented way to
associate an amount with its required properties is a problem to me.

It is instructive to look at each of the X12 segments in which one or more
'amount' DE's are defined.  There are some instances in which a property of
an 'amount' cannot be discerned from the segment documentation.  There are
also instances in which a semantic constraint property has multiple
simultaneous values.  And there is at least one instance in which the
ability to express an amount in non-numeric terms is provided.

Cheers,
         Bob



-----Original Message-----
From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
Sent: Thursday, May 31, 2001 2:05 PM
To: 'William J. Kammerer'; ebXML Core
Subject: RE: William defends Todd's dignity, too... and also wonders
where the qualifiers went...


William:

There has been a good deal of discussion about the use of qualifiers
generally in core components design in the working groups.

I will attempt to paraphrase:

In EDI syntaxes, qualifiers are used to indicate semantic specific to the
local use of a re-usable component (for example, is this a Buyer party or a
Ship To Party?)

In some XML syntaxes, a similar approach is used (xCBL uses qualifying codes
in many places, although certainly not everywhere, and usually for agreement
with EDI syntaxes).

In other XML syntaxes - especially those based on XML DTDs, which have a
weaker concept of a "code list" or "enumerated datatype" - semantic
qualification is performed with element containership. Now that we have a
standard schema language to work with, that gives us strong typing
capabilities, we have another mechanism for indicating semantic
qualification with element names: a Buyer Party becomes an element named
"BuyerParty" with a type attribute that indicates it is a "Party".

In short, depending on how core components are bound to a syntax, qualifying
codes may or may not be useful.

I believe that the core components models did not indicate complete
eumerations for the semantic qualifications of core components, but merely
indicated the types of existing lists that might be useful.

Ultimately, what we care about in the core component models is a range of
standard uses, whether these are bound to a syntax as qualifying codes or
with some other mechanism. Given the way XML processors work, I think it
very likely that many XML formats will not use qualifying codes as the main
way of indicating local semantic qualifications, because they are an
inconvenient way to model XML data, having the disadvantage of containing
within their content the information about what they are, rather than having
this be present as a container, and thus immediately available to
event-based processors such as those using a SAX interface. I may be wrong.

Regardless, I don't think the issue is one of qualifying codes or not, but
merely one of capturing a standard set of qualifiers that can be bound to
specific syntaxes in many different ways.

I hope this summary of discussion at some of the ebXML meeting will prove
helpful.

In response to Todd, I would say that perhaps we have not yet made the
effort to enumerate all of the potential uses for these components. I
believe that we have done a lot of work that may be useful in producing such
an enumeration, but that this activity was not determined to be in scope up
to this point. Maybe now is the time to start working on a standard set of
local uses for each of the components?

Cheers,

Arofan Gregory

-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: Thursday, May 31, 2001 11:38 AM
To: ebXML Core
Subject: William defends Todd's dignity, too... and also wonders where
the qualifiers went...


Todd Boyle asks why don't the dateTime and Amount core components have
qualifiers which explain what the dateTime and Amount are all about?
This was a reasonable question which should be dignified with an answer.
Perhaps it was missed because it was posted to the ebxml-dev mailing
list rather than the Core Components mailing list.  See
http://lists.ebxml.org/archives/ebxml-dev/200105/msg00009.html.  To
repeat Todd's question: Is 'qualifier' in the doghouse?

Anyway, Todd's asking the same questions I asked a long time ago, to
which I never received an answer.    See the third paragraph in
http://lists.ebxml.org/archives/ebxml-core/200104/msg00279.html.

Todd's question should be seriously mulled over - this is extremely
relevant to Core Components design.  And it is a bit more important than
cat-fights over XML syntax.

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

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