Re: [ubl-ttsc] suggestions for scenarios

[jon.bosak@sun.com]

Trying to hold up my end of a real conversation on this while I'm
gadding about the Continent is hopeless, so please just consider
this as input for your consideration at leisure.

[tmcgrath@portcomm.com.au:]

| 1. Entity A sends entity B a UBL document that satisfies a normative UBL 
| document schema.
| 2. Entity C sends entity D a UBL document that satisfies a normative UBL 
| document schema but that has been customized by tighter restriction.
| 3. Entity E has generated a set of components and schema they want
| to call 'UBL XYZ' and have it viewed as a normative UBL document.

The case that I find most interesting is the one in which an
industry data exchange organization wishes to customize UBL for
use in that particular industry -- for example, "EIDX UBL," "CIDX
UBL," etc.  If this customization just consists of restrictions to
our schemas, then we have case 2, which is (we hope) not
problematic.  But if the customization includes some additions to
our schemas, then we have case 3.  My hunch is that this will be a
common case, and this is the one that most concerns me.

Here's my description of the use case that I'd be most eager to
see us develop clear guidelines for:

   The XYZ industry data standards organization wishes to
   standardize an XYZ invoice schema based on the UBL invoice
   schema.  The XYZ invoice restricts some UBL invoice elements
   and adds other stuff specific to the XYZ industry.  Some of the
   added stuff consists of modular pieces that can be stuck onto
   the end of a standard UBL invoice, and some of it consists of
   additions to things that are already in there.

   The solution for this use case should include the incorporation
   of some of the added stuff into the UBL library and the
   submission of this stuff via that route into TBG17
   harmonization.  Deciding which additions should go into the UBL
   library is part of the problem to be solved.

I don't have any useful input for how this use case should be
addressed, I'm just trying to enunciate the problem using suitably
precise technical terminology. :-)

Best regards,

Jon

=============================================================
Correspondents: Please be aware that I am traveling in Europe
19 January through 6 February and will therefore be slow in
accessing and responding to email.
=============================================================

   Date: Wed, 21 Jan 2004 02:41:57 +0800
   From: Tim McGrath <tmcgrath@portcomm.com.au>

   i am trying to simplify and clarify the different scenarios noted in the 
   compliance discussions.  i intend to use these for the position paper of 
   customizing UBL, so i would like feedback from this group..

   my list currently reads....

   1. Entity A sends entity B a UBL document that satisfies a normative UBL 
   document schema.
   2. Entity C sends entity D a UBL document that satisfies a normative UBL 
   document schema but that has been customized by tighter restriction.
   3. Entity E has generated a set of components and schema they want to 
   call 'UBL XYZ' and have it viewed as a normative UBL document. 
   4. Entity F wishes to generate a set of components and schema using UBL 
   NDRs and some existing UBL components but not have it viewed as a 
   normative UBL document.  
   5. Entity G wishes to use some existing UBL components in their business 
   vocabulary but not have it viewed as UBL.

   -- 
   regards
   tim mcgrath
   phone: +618 93352228  
   postal: po box 1289   fremantle    western australia 6160