OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl] Information items in 2-prd2-cd minimal instances


Hello UBL TC,
according to my past experience I agree it is difficult to find the right
minimum subset for evry document/information.
However I know the same problems have been experienced and solved with
UN/EDIFact where the base standard was not immediately sufficient for all
use cases.
This way some user groups was born around UN/CEFACT to address such kind
of problems.   Their main task was the creation of guidelines for
UN/EDIFact messages real use on specific areas (transportation, shipping,
...)
Major companies from shipping and transportation make use of these
guidelines and they are members of these bodies.

-------------------------------------------------------------------------
About IMO the mandatory minimum data is:
 IMO
 HAZARD CODE
 Hazard code identification:
 - IMDG Class Number
 - IMDG Sub-Class Number
 - RID Class Number
 - CFR49 Codes

...but there are more info about at

   http://www.smdg.org/itigg/index.jsp

under

   Documents->Downloads->...
                         Transport Freight Movements - version 2.0
-------------------------------------------------------------------------

There are many user group for different areas, the once I know for
transportation and shipping are grouped under SMDG:

*************************************************************************
The International Transport Implementation Guidelines Group

http://www.smdg.org/itigg/index.jsp

ITIGG is an international group of experts engaged in the development and
implementation of
UN/EDIFACT standard messages for electronic trading in the transport
industry.
ITIGG is a sub-group of TBG3, the UN/EDIFACT Message Development Group for
Transport.
ITIGG develops recommendations which provide software developers with a
series of simple, straightforward tools to assist in designing
applications which can be used for trading electronically throughout the
world, and to clarify the intentions of the designers of key UN/EDIFACT
messages.
In the longer term the group aims to harmonise messages used in the
transport sector, so that the same message specifications can be used
anywhere in the world.

*************************************************************************
http://www.smdg.org/BEST/

BEST (Business Group for Electronic Commerce Standards in Transport) was
established in 1994 by a group of companies and organisations in the
transport sector primarily to support the work of the European EDIFACT
Transport Group EEG2.

BEST is involved in the Electronic Commerce standards, including:
- EDI (Electronic Data Interchange).
- Internet communication especially ebXML.
- Automatic identifications techniques for transported goods: barcoding,
such as the Multi Industry Transport Label (MITL), Radiofrequency tags?
etc.
- Mobile datacommunication.

*************************************************************************
User Group for Shipping Lines and Container Terminal
(SMDG - Shiplanning Message Development Group)

http://www.smdg.org/

SMDG is a non-profit foundation, run by and on behalf of companies and
organizations working in the maritime industry, like container terminals,
ocean carriers and related companies and organizations.

SMDG develops and promotes UN/EDIFACT EDI-messages for the Maritime
Industry and is an official Pan European User Group, recognised by the
UN/EDIFACT Board.
------------------------------------------------------------------------
------------------------------------------------------------------------


I hope into these sites you can find some more info to have a good minimum
data subset, however both the shipping and transportation sectors are not
so precise and advanced as we could imagine, they are really different
from banking or others fields.

For some countries like US there is a "Container Security" project which
is embracing also Ports security, into this direction there could be some
more mandatory data for a set of documents where exchanged to/from the US.

By now as we are talking about shipping maybe is not an actual requirement.

Hope my info are useful in some way, moroever I think some of or all of
these user group should have a contact with us in the future even if they
have already a contact with UN/CEFACT.

Best regards

UBL ITLSC
co-chair
Roberto Cisternino



Sylvia Webb wrote:
---------------------------------------------------------------------------
Ken,
Based on my experience, I have serious reservations that there can be a
universal minimum subset defined by the UBL TC. Such a subset can run afoul
of local, regional, and international laws which specify minimum data
requirements for specific transactions. Additionally, purchasing or contract
law can dictate what a minimum subset should be between trading partners.

As an example, if I establish a business relationship with a EU company or
government agency, I have different minimum data requirements that may be
specified in their subsets or guidelines plus additional requirements
specified by U.S. and California laws. If I am shipping hazardous goods, I
have yet another minimum subset of data required. Finally, depending on what
is specified in any purchase order or contract that I receive, I can have
multiple minimum subset requirements based on the legally binding
requirements of those documents. These minimum data requirements do not
include additional data that I may wish to include to satisfy any best
practices which my company wishes to follow.

IMO, there isn't any way that a standards body can have access to all of the
subject matter experts needed to consider all of the business rules and laws
which would be needed to determine an internationally acceptable minimum
subset.

Regards,
Sylvia

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
Sent: Friday, August 11, 2006 8:34 PM
To: Universal Business Language
Subject: [ubl] Information items in 2-prd2-cd minimal instances

As part of the analysis of 2-prd2-cd in the context of the extension
methodology and my concepts of working with minimal instances of only
mandatory elements, I thought it best to supplement the XPath report files
with a "minimal mandatory report" for each of the 31 document types:

   http://www.oasis-open.org/committees/document.php?document_id=19695

Each report enumerates the absolute minimum mandatory element and attribute
information items for the given document type.  The smallest instance that
would validate with the schema would be an instance with only (and all)
these information items.

The reference numbers at the left are the XPath reference number from the
complete XPath file that enumerates one of every information item.  I am
unable to put the complete 283Mb XPath package in the repository, so I've
corresponded with OASIS staff to see how I might do this.

By reviewing the minimal instance information items, I wonder if the UBL
subject matter experts might detect any faults in the model design.

I was interested to see what information items are, I believe, those that
would need to be supported in a "minimal implementation" as I described to
Jay in my response quoted below.

While the vast majority of transactions accepted and processed by a system
would be instances meeting all of the business rules of the recipient, in a
"minimal mode of operation"
selectively engaged by the recipient in order to transact with a new
business partner not meeting the business rules, the system could act solely
on the minimal mandatory information which is guaranteed to be found in
instances of *all* UBL implementations.  This suspension of business rules
would not be the norm as eventually the sender would change their system, or
the transaction with the sender might just be a one-off, but for that period
of time that the sender does not meet the complete business rules of the
receiver, the receiver could transact (with the required non-electronic
support
information) with the minimal instances.

The question is, are there sufficient mandatory information items in the
minimal document models with which to do this?

I hope this is considered helpful.

. . . . . . . . . . . . . Ken

At 2006-08-11 10:11 -0500, I wrote:
>At 2006-07-31 16:10 +0100, Jay Cousins wrote:
>>3rd para. So serendipity is conformance to the UBL model *without*
>>extensions - yes?
>
>Yes.
>
>>- which makes perfect sense - but for this a UBL compliant system
>>would need to implement the entire UBL model, including all optional
>>content, no?
>
>I don't think so ...
>
>For example the absolute minimum invoice instance has only the
>following information items:
>
>/in:Invoice/
>/in:Invoice/cbc:ID
>/in:Invoice/cbc:IssueDate
>/in:Invoice/cac:AccountingSupplierParty/
>/in:Invoice/cac:AccountingCustomerParty/
>/in:Invoice/cac:LegalTotal/
>/in:Invoice/cac:LegalTotal/cbc:PayableAmount
>/in:Invoice/cac:InvoiceLine/
>/in:Invoice/cac:InvoiceLine/cbc:ID
>/in:Invoice/cac:InvoiceLine/cbc:LineExtensionAmount
>/in:Invoice/cac:InvoiceLine/cac:Item/
>
>>If not how can serendipity apply? It's not clear to me if the minimum
>>requirements are stated or not.  I assume that 'minimum requirements'
>>are support for the whole UBL model.
>
>Personally, I think that 'minimum requirements'
>is support for only the mandatory elements.
>
>If an invoice processing system supported only the absolute minimum
>elements above, and the invoice gets paid without need for *any*
>optional elements, then payee gets his money from the payer without
>either having to change their systems.  Obviously this would probably
>be an optional mode of operation, as having a number of the optional
>items would often be required to meet business needs by the paying
>organization.  But by encouraging deployments to have such a mode of
>operation, then two brand new trading partners could use their existing
>implementations of UBL with an agreement to work, perhaps just one-off
>or for a temporary period of time, in this "minimal mode" until such
>time as their systems can be modified to meet more business requirements.
>
>Without propagating this concept of being able to work, even just
>optionally, in such a minimum mode of operation, I'm worried that UBL
>deployments will create obstacles for new trading partners to either
>quickly or just temporarily do business by mandating changes to
>existing implementations.
>
>>However, Section 5 of the document shows that a system that does
>>support the UBL model is 'UBL-open'.  So I think the meaning here is
>>that serendipity requires a UBL-open system?  Can you make this explicit?
>
>Yes, my thought was that a UBL-open system is one that supports the
>absolute minimum in a mode of operation that suspends business rules
>that would otherwise cause the instance to be rejected.
>
>Whereas a UBL-conformant system is one where the business rules are not
>suspended and a UBL-conformant instance not meeting the rules is
>rejected, but one that does meet the rules is accepted.




--
UBL/XML/XSLT/XSL-FO training:         Vårø, Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]