Re: [ubl-comment] To define propietary business documents

[Tim McGrath <tmcgrath@portcomm.com.au>]

You are correct in identifying that UBL is an emerging standard.  As 
such, there are decisions to be made about when to adopt.

I would like to point out that the 0p64 version published in March this 
year was an early release aimed primarily to solicit feedback from the 
market.  For example, many of the questions you raised also came up from 
other groups and are being dealt with.  Therefore, whilst i will deal 
with your issues individually, i would like you to be aware that the 
0p65 version due for review in four weeks time will be significantly 
more mature than the one you are dealing with.

1. How stable is the re-used types defined in the package? We may not
afford subtle changes on our defined schema from time to time if we decide
to follow and stick to the UBL/CC methodology. Also the parallel efforts
between UN/ECE CC and UBL give me two directions to follow. For example,
will UN/ECE CC work out another library, which forms a competing standard
with UBL.

I am not sure that UN/ECE CC and UBL do give you two different 
directions.  UN/ECE CC will develop syntax independent core component 
definitions, UBL will develop the XML instantion of these.
Your concern may be that the work of UN/ECE CC is also emerging and as 
such there are no formalised Core Components from which UBL can draw its 
required models.  It is the intention of UBL to submit all our 
de-contextualised BIEs as candidate core components to the relevant body 
within UN/ECE (presumably CEFACT) when the mechanisms are in place to do 
so.  In fact, most of the members of CEFACT dealing with the CC 
harmonization issue are active UBL participants!
The way I see it is that the only two alternatives to UBL/CC/ebXML are 
to adopt proprietary vocabularies (ie those with retained IP or licenced 
for use) or to roll your own.  The choice is yours, but most of us are 
part of UBL because we are tired of seeing the interoperability 
opportunity of XML slipping away.

2. I still have difficutlies in applying the UBL/CC methology, for example
the use of Id and Code types. (Should IMO Hazard Class use Id or Code? In
the 0p64 spreadsheet, Id is used.)

This was raised by others during our recent review period.  It is a 
result of trying to adhere to the ebMXML Core Component Technical 
Specification rules for repressentation terms and core component types, 
not directly a UBL feature.  
The interpretation of Code or Identifier has been much debated.  We 
currently have a UBL position paper on this that appears likely to be 
accepted by the group.  If you are interested it is available from our 
list archive at 
 http://lists.oasis-open.org/archives/ubl-lcsc/200206/msg00023.html

3. I can't access to the methodology (or tools) to translate BIEs to the
XML Schema. What I have is the Naming and Design Rules document.

In theory you should be able to hand craft the XML Schemas using the NDR 
rules (and the examples in the 0p64 distirbution copy).  However, we 
acknowledge that some XML Schema specific features are not in the 
current model and must be assumed.  This is one of the changes we are 
making with 0p65, to include all XML Schema metadata required by NDR 
rules.  In addition the actual perl script built to do the initial 
transformation is being re-engineered and we hope to also publish this 
as part of the package.

4. The results derived from the methodology seem strange to me. For
example, I have to use VoyageId instead of VoyageNumber (a more common
business term) and PortCallDateTime instead of PortCallDate (they don't
need time). Also there are requirements to supply supplementary CCT
Components, e.g. Identification Scheme Name, whose values are not yet well
defined or standardized. Also, the resultant model gave me a much more
complicated message than a propietary methodology that I can use. The
complicated message may stop the users from adopting it.

Once again, we had similar comments from our initial reviewers as well. 
 There are several different questions here, the first three relate to 
the Core Component Technical Speicifcation naming rules adopted by UBL.  
Firstly, it is a fact of life that business terms do not follow formal 
rules like to ones proposed by the CCTS.  The UBL remedy for this is to 
add 'business term' as a new attribute to our meta-model, allowing us to 
define the BIE VoyageId as the business term 'VoyageNumber' - even if 
they aren't actually numbers!
Secondly, we have proposed the the Core Component Technical 
Specification editors that they should rationalise the Core 
Component/Representation Term relationship to allow such things as Date 
rather than DateTime.  This would simplify many confusing parts of the 
naming rules.
Thirdly, in situations where the CCT component requires information that 
is not known this should be stated or omitted .  If the component is 
unnecessary then it raises questions as to whether the correct CCT was 
used.  For example, if you don't have an identification scheme name, is 
it really an identifier (using the CCT definition "one instance of an 
object within an identification scheme from all other objects within the 
same scheme")?
The final part of your question is very important.  Proprietary messages 
will always be smaller and arguably simpler than standardised ones.  The 
success of building good standards is not to make them too large or too 
complicated. (we could suggest EDI standards as examples of this :-) ). 
 The reason UBL is not going to be the smallest, simplest schemas for 
anything is that we are trying for the 80/20 , 'most amount of value for 
least amount of complexity' position.  Our goal is interoperable 
documents.  For example, 90% plus of your hazardous goods data will be 
required by the next port of call - who will want their own context 
driven extension to the message.  Whilst your client is the HK 
Government, it will be far more attractive to the shipping companies who 
have to build these messages, if you offer them interoperability with 
other ports and other applications.  I have personally built three 
different hazardous cargo reporting systems - each using the same data 
but different vocabularies.  As i said at the beginning, some of us are 
tired of doing this.

Might I suggest you will end up with a more re-usable, longer living 
solution by using the UBL/CC philosophy as the basis of your design, 
even if the final result is your own customisation.  Whilst it may not 
be possible to have UBL compliance at this stage, but I would encourage 
you to build upon the foundations.

PS
Sorry for the long winded response, I hope it doesn't put you off!

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142