Re: [ubl-dev] UBL in real life shipping web services integration

[constantine@expeditebiz.com]

Hi Tim ,

>Thank you for your encouraging words on the value of UBL to your 
>application.

UBL is an impressive effort and is a good basis for what we want to do.

>Your suggestions come at a timely moment as we are currently gathering 
>requirements for the next release of  UBL (hopefully to be released 
>later this year).

I've an access to a dozen of proprietary XML API's as well as a good knowledge 
of the public XML standards and can say UBL is very valuable because the tag 
names are clean, simple and there no many nesting levels - very important from 
implementation point of view.

>You have correctly identified that we could strengthen the UBL library 
>in the area of shipment.  From what you describe it appears that you 
>require some finer grained information components or specific code sets 
>than those currently available.  We would very much like to discuss this 
>further with you.

You are very welcome. 

[...] the Japanese ECALGA requirements 
were submitted to UBL (contained in the document [...]

I wil use this document. Before to begin working with this formal document I will 
like to discuss some matters informally to collect the info for the current state 
of the matters.

>Also for your interest, one of the new documents we will be introducing 
>in the next release of UBL is the Certificate of Origin which 
>incorporates many additional trade and transport related components.

In this regard I am wondering if there is a document where I can see
the following information:

Carrier - DHL, UPS, FedEx, USPS, etc.
Services - 2Day, GROUND, etc.
Package - Express Envelope, etc.
Weight - value
Dimensions - value
DropoffType/Pickup - residence, business, etc.
Payment - billing shipper, billing recipient, etc.
Declared Value - value

These are the missing tags. If you have them in the standard we can build our 
product from here.

The tags and vocabularies are the most important part and have to be chosen very carefully. 
Our customers build interface and integrate our web service in existing IT infrastructure 
and changing tags at a later phase is very expensive.

>With respect to your desire to create a 'virtual carrier interface', 
>whilst this seems like a sensible architectural approach it does not 
>relate to scope of UBL.  

This is our expertise and ExpediteBiz will develop this 'virtual carrier interface'. In order it to 
be easier for our customers we need standard tag names and vocabularies. We will build our 
product on this foundation. Again I think UBL is a good basis.

Also there is one more thing. Looking at OASIS CIQ latest development - NAL (Name and 
Address Language) has branched in 3 levels - Basic, Advanced, Enterprise.
In my opinion this is a big mistake and better not to happen to UBL or other standard.

Why mistake? Because it is very hard to define the border line between Enterprise, Advanced 
and Basic. These are very artifical borders and you cannot fit the real life requirements in 
these borders. If UBL is intended to small and medium size business this fact does not means 
you have to omit Entreprise level features. 

In my opinion the differentialtion has to be business oriented. For my case - the differentiation 
among the carriers services is what matters, not the size of business. For example all major 
carriers have different shipping services and that is what differentiates them. So our customers 
using for example one carrier and building interface to our web services will want to see only
 this carriers' shipping services tag names, not all possible shipping carriers' tag names. 
Otherwise this is hard to support and usually the documentation is the last thing to be read. 

Constantine
ExpediteBiz
ExpediteShip.com