Re: Summary of XML Datatypes as required for B2B applications

["Martin Bryan" <mtbryan@sgml.u-net.com>]

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

partyinfo.doc