[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ndrsc] Defining the logical model
i am not sure what some of the terms you use are, but from the very first version (april 2002) we have had a clear policy on this in terms of the models. I dont see why the schemas should not match this - in fact i suggest it is a good idea they dont change it (and that we keep consistent terminology). 1) For all ABIEs that have the potential to be used in schemas that cross functional boundaries (i.e. transportation, procurement) - place them in the CAC module. (what is CAC? this is called the Reusable schema. ) 2) For all ABIEs that are part of a unique subset (only of value to a subset of business processes within a functional area) - place in the internal schema (i have no idea what this is) 3) For all ABIEs that are unique to a particular message - place in the control schema. (we starting out this way but from the earlest library it became clear we could not easily segregate unique ABIEs. What has evolved is that only the document level ABIE are in this schema. furthermore, if we want to encourage re-use then it makes sense to make every ABIE potentially re-usable. NB even apparently obvious 'unique ABIEs' like OrderLine was found to be re-used!) I can understand Michael asking the question, but is this an NDR issue at all? All ABIEs in the Reusable model go in the Reusable schema, all ABIEs in the individual document models go in their respective document schema. We have been doing this for 2 years and it works fine. As Mark says, it is the LC model that determines where these things should go, so why duplicate/confuse everyone by having potentially different rules in the NDRs? Am i missing something here? CRAWFORD, Mark wrote: >Michael Dill has raised the issue to me that we have not adequately defined how to determine where each of the UBL ABIE complex types should be defined. Specifically, which types are defined in the common aggregate components module, which types are defined in the control schema, and which types are defined in an internal schema module. In searching the current language of NDR, I found that there is general language in section 3.6.4.1 but no specific rules. In looking at the current spreadsheet, I find no indicator that would support Michael processing the spreadsheet appropriately. > >In my opinion, this is a joint LC and NDR issue. I see that NDR should provide some more specific rules in support of the general language, and LC should make the ABIE by ABIE determination. I would propose the following: > > 1) For all ABIEs that have the potential to be used in schemas that cross functional boundaries (i.e. transportation, procurement) - place them in the CAC module. > > 2) For all ABIEs that are part of a unique subset (only of value to a subset of business processes within a functional area) - place in the internal schema > > 3) For all ABIEs that are unique to a particular message - place in the control schema. > >Thoughts? > >Mark > > >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-ndrsc/members/leave_workgroup.php. > > > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]