Re: Summary of XML Datatypes as required for B2B applications

[MKudela@uc-council.org]

Thank-you for   reviewing  our work in such a timely manner. Yes, I will be
in Brussels and I would consider it a privilege to work with you and other
XML experts  within the core components group on generalizing and making
our preparatory work more useful.

Melanie Kudela
EC Technical Manager
UCC, Inc.
Princeton Pike Corporate Center
1009 Lenox Dr., Suite 202
Lawrenceville, NJ 08648, USA
609-620-4514
mkudela@uc-council.org


                                                                                        
                    "Martin Bryan"                                                      
                    <mtbryan@sgml.        To:     <MKudela@uc-council.org>              
                    u-net.com>            cc:     <ebxml-core@lists.oasis-open.org>,    
                                          "XML/EDI" <xmledi-list@lists.bizserve.com>    
                    04/18/00 06:07        Subject:     Re: Summary of XML Datatypes as  
                    AM                    required for B2B applications                 
                                                                                        
                                                                                        



Melanie

In all the unnecessary furore that my attempt to show how XML Schema
Datatypes could be used to provide a formal model for defining the
datatyping needs of businesses have produced, your contribution stands out
like a shining beacon.

> However, the EDI knowledge should not be the only input to the process .
> Because of our history of working with our members on EDI industry
> standards, we know we must adhere to two principles when we define the
XML
> standards roadmap for our members:
>      1. accomodate the business needs, and
>      2. standards do not drive business behavior,  but accommodate
business
> behavior.

Oh how I agree with you!

> The  EDI inputs are  not sufficient by themselves to describe the
business
> landscape of  tomorrow. Converting EDI to XML in n number of days  is
> possible, but not enough to accomodate business behavior.

Hallelujah!!

>That is why the
> UCC program consists of
>      1. a business model represented in UML which is developed with the
> business community;
>      2. a data dictionary which is based on EDI knowledge but is not a
> one-for-one map of EDI to XML;
>       3. a set of XML metadata which is derived from 1. and 2. and the
> resultant XML schema.

The only way to go.

> We would like to see the ebXML Core Components define a  documented set
of
> standard of core components  in XML, down to the level of the document,
> "Using XML Schemas to define B2B Datatypes", so that we could comply to
> these core component definitions.

So would I. As an interim what the UK Data Harmomization Group have
suggested is that when defining a "format" or a "value domain" within the
ebXML spefications that Perl patterns (a la Schemas) and enumeration lists
be used as a formal way of documenting the semantics. (We did a first set
of these, covering Party and Payment Information Batches, in London last
Friday.)

>  I'm contributing a draft of the UML model, data dictionary and schemas
of
> a business process that we are currently working on with our members
where
> we  address our member needs for synchronizing product and service
> information between buyers and suppliers. Both business needs and EDI
> knowledge have been useful in gathering the information. We  also have
> work-in-progress in other areas, such as pricing, markets, purchasing.
> Standard, agreed upon core components from ebXML would facilitate the
ease
> of adopting these  XML transactions for our members.

Thank you very much for this useful contribution. There are, however, a
couple of points that I need to take up with you.

In discussing the best way to handle Party on Friday the UK Data
Harmonization Group came to the conclusion that Party was an abstract
concept that was useful for a number of associations between messages and
information sets that contain subsets of the abstract data set relevant for
a particular party role. The primary cause for this decision was a study of
the relationship between the Contact and Party segments across a wide range
of messages. It turns out that Contact is just a subset of Party that needs
to be embedded within Party. By making Party abstract we could make Contact
another association with the abstract Party class. I attach the (still
incomplete) forms that we filled to document Party using the neutral format
suggested by Mr. Sugamata. (Sorry, I have no electronic form of the UML
model at this stage - this should be ready shortly.)

In your model you have Party as a container for information relating to the
Supplier, Manufacturer and InformationProvider. In our model these three
components become concrete representations of the abstract Party component,
the names of the representations being taken from the names of the
associations (qualifying roles) that identify the use of the abstract
class.

Similarly with the attributes you assign to the Date class. These are
really associations that identify a particular use of the Date abstract
class. The reasons that they want to be associations rather than attributes
is that where each of them can be used is entirely dependent on the route
taken to reach the Date. Things that are routing dependent should be named
as associations. Again you can use the association name to identify a
specific occurrence of the abstract class within a message.

The final point I would like to raise at this time (I'll raise others later
probably!) is that of the complex names you use. Too many of your UML
attributes have names that start with some or all of the name of the class.
This makes for unnecessarily complicated naming of the XML representation
of the class, as your XML Schema shows. Where possible it is recommended
that those parts of names that are reflected in the containing class, or in
the names of classes that reference the class, be omitted. I would ask you
to try to write out the path to each element of your message. If you end
up, as you do, with sequences like
ItemSpecification/Details/ItemClassification/ItemIdentification/GlobalTradeItemNumber

then you probably have too much repetition of Item, and need to consider
the relationship between Specification/Classification/Identification/Number
if you want to avoid tautology.

Are you coming to Brussels for the ebXML meeting? If so we need to get
together to discuss how your excellent preparatory work can be generalized
for use within the core components group.

Martin Bryan


(See attached file: partyinfo.doc)

Microsoft Word 4