[ubl-lcsc] RE: David RR Webber

when I realized my image of PriceDetails and DeliveryDetails I hadn't no idea that I'am starting a discussion like yesterday. I thought it will be very useful to generate the proposed BIEs with XML Spy and it is allowed to use the specified Core Components of the "Catalogue of Core Components". I realized, that in xCBL 3.0 occurs a high number of components, that are not really necessary in our first stage. And I have seen, that the specified Core Components of the "Catalogue of Core Components" represents this information in much more revised form. It will be better for our work, or not?

The reason why I'am using XML Spy is, that I have to evaluate this product and I have seen it will be shorten our work, because it represents all defined Components in much more clearify form and in the required XML Syntax. If I have do some changes, because there is for example a recommendation of naming or design of structure at any time, it will be very easy to do this with XML Spy. So I can use this work for both things: first for the documentation and for the realization of real BIEs based on XML Syntax.

I've read the paper of David R.R. Webber and I've seen that this paper ingnores the Core Component Specification completely. It mentions the name Core Components sometimes. But I guess, that will be not really necessary to this in that specification. This specification describes the interface for importing components (desribed in any EDI/XML-format) into the registry and for exporting that components (in another EDI/XML-format) from the registry. You can do a mapping between different formats by using the element "Association". This element proivdes the reference to related components of different standards.

That idea of that specification is not bad. I had nearly the same idea in 1999. I thought, it will be good idea to realize one interface schema (called MasterSchemaDefinition) where you can describe every XML/EDI structure with it and where you can map between structures without writing any mapping rules by using any propietary mapping language or XSLT respectively. The following attachement shows you one part of the MasterSchemaDefinition. This project was stopped last year by my former company and that is the reason while I'am working with you yet.

I have seen, this kind of interface will be a right of exist for the vendors of middleware-systems. They say you can use your own format in future and it doesn't matter in which format your partner would like to get your message. They would like to do the mapping with their registry interface, because this have all information of all XML/EDI-Standards and all associations between the standards in it. This makes the business connection between partners very easy. That makes sense.

But there is a big question. Who one can use the real benefit of XML? I say, not the vendors of ERP- or another business-systems i. I think it make not sense to standarizing directory services/protocols, messaging services/protocols, collaboration profiles, business processes and describing this by using XML and you can use every format/standard for describing documents/standards further more. To collaborated partner can exchange their collaboration profiles and business processes directly and the documents/components must always going through one middleware-system for mapping from one format into another by using the CCR-interface. That is not the benefit of XML. And everyone knows that. Because you have to exchange entire business documents in our own format and you can not exchange any non redundand and small business information entities which are embedded in the business processes directly. I think, it make more sense to create XML-based Core Components and Business Information Entities with all advantages of the XML-Syntax and ebXML and associate all the other standards to this unified Core Components and BIEs. To do this very efficient, we have to change the interface structure from David RR Weber. This structure must be align to the structure for creating Core Components and BIEs.

You have been very busy providing us with a substantial set of files to study before tomorrow's meeting! They are very interesting and, I guess, will need much more time to concentrate on their content definitions. In the meantime your suggested presentation of the date certainly looks rather useful to aid our work.

I wanted to ask you if you have had a chance to look at the newly circulated CCI/CCR specification recently sent out by DW? I am concerned by the usual project scope creep and also wondered about the potential overlaps/collisions with our UBL work? Do you have any ideas on these questions?

Sue Probert
Senior Director, Document Standards, Commerce One Labs
Commerce One
Tel: +44 1332 342080
email: sue.probert@commerceone.com

ubl-lcsc message