Re: [ubl-ttsc] suggestions for scenarios

["Chris Nelson" <chris@dimension-edi.com>]

Tim,
In the context of tools we should concentrate on (1) and (2), particularly
(2) as I suspect this will be the most common use case. (3) is long job as
it demands some form of development and approval process. (4) and (5) demand
just a development process and should be easier than (3).

Do we not have an extension use case which is like (2) but adding something,
with or without wishing it to be a part of the core standard? I suspect this
will be a common use case as UBL schemas evolve.

Chris


----- Original Message ----- 
From: "Tim McGrath" <tmcgrath@portcomm.com.au>
To: <ubl-ttsc@lists.oasis-open.org>
Sent: Tuesday, January 20, 2004 6:41 PM
Subject: [ubl-ttsc] suggestions for scenarios


> 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
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ubl-ttsc/members/leave_workgroup.php.
>
>