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: AW: [ubl] Definitions for re-used ABIEs was:Re: [ubl] for Anne(?)AW: [ubl] Issues triage ad issue 18,2


Hello Michael,

I apologize for not catching your original mail, which came during our 
break, so was lost in the large quantity of mail I had when I returned. 
 I will add this.

Thanks,

-Anne

dill2@gefeg.com wrote:

> Anne,
> sorry, next time I'll mention explicitely, if something is a comment 
> for the issue list.
> Please do me the favor to add my comments to 18.2. At least the topic 
> 2/  and 3/b refer directly and immediately to 18.2 I think, it is 
> worth to be considered as a comment, if somebody disagree with the 
> existing proposal as of the issue list and if this somebody wrote 
> arguments.
>  
> Dear All,
> please let me underline that Issue list line 113 with the Commend Id 
> 'b.1' is a very basic issue for CCTS compliance and should be 
> considered as an UBL 1.0 issue
> Thanks
> Michael
>
>     -----Ursprüngliche Nachricht-----
>     Von: dill2@gefeg.com [mailto:dill2@gefeg.com]
>     Gesendet: Montag, 5. Juli 2004 19:14
>     An: 'Tim McGrath'
>     Cc: ubl@lists.oasis-open.org
>     Betreff: AW: [ubl] Definitions for re-used ABIEs was:Re: [ubl] for
>     Anne(?) AW: [ubl] Issues triage ad issue 18,2
>
>     I think that this discussion has been addressing different points:
>      
>     1/ Tim,  you are obviously making a point about ASBIEs in general.
>      
>     2/ In 18.2 Yukinori Saito is raising a Controlled Vocabulary issue
>     and he proposes replacement of Customer by Seller. But shouldn't
>     the replacement proposed be Buyer instead? 
>      
>     3/ I am talking about BBIEs and the UBL data model itself. There
>     are two issues:
>      
>     a) CCTS compliance
>      
>     The DEN and definition should always match each other. In the
>     cases of the two BBIEs that Yukinori Saito refers to,  namely
>     'MaximumBackOrderQuantity and MinimumBackOrderQuantity in LineItem
>     (ABIE)', the DENs and definitions do not match, as required by
>     CCTS. Either i) the DEN is correct in which case the model is OK
>     but the definition should not include any mention of customer (or
>     seller or...) or ii) the definition is correct in which case the
>     UBL data model DEN needs changing and as a consequence the UBL
>     data model will need to be changed. A new ABIE is required which
>     will enable specific BBIEs to be defined to include the concept of
>     'Customer (Seller?Buyer) approved' in their name as an extra
>     qualification.
>      
>     b) The UBL business requirement
>      
>     I do not understand from a business perspective why a seller
>     should ever approve a backorder quantity to be backordered. IMHO
>     it is a customer (buyer) who may do this.
>     But in any case I even tend to disagree that any party role is
>     pertinent to this definition and therefore I favour case a) i)
>     i.e. the removal of the concept of party from the definition, as a
>     proposed solution to this issue.
>      
>     Michael
>      
>     BTW:
>> The EDIFIX view  you attached is not showing the correct definitions.
>     Please let me draw your attention to the reason of the EDIFIX view
>     I sent: It shows the four places where the Line Item.Details is
>     reused. And this is what the text of the email said. And
>     the definition an user can see is correct. And there is just one
>     definition and not many. (Where I was not correct is to use the
>     term ABIE inestead of ASBIE.)
>      
>      
>      
>      
>
>         -----Ursprüngliche Nachricht-----
>         Von: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
>         Gesendet: Sonntag, 4. Juli 2004 03:56
>         An: Michael Dill
>         Cc: ubl@lists.oasis-open.org
>         Betreff: [ubl] Definitions for re-used ABIEs was:Re: [ubl] for
>         Anne(?) AW: [ubl] Issues triage ad issue 18,2
>
>         i think what you are talking about is the definitions of the
>         ASBIE for Line Item. Details.  That is, where Line Item.
>         Details is re-used it has a different definitions.
>
>         So the place to look for its different usages is at the ASBIE
>         level.  We dont need a qualifier as the context of the ABIE in
>         which the ASBIE appears gives that.
>
>         The qualification (if any) of any ABIE happens when it is
>         re-used (ie when it is used in an ASBIE)  so that is where the
>         qualifers should be.
>
>         So we have things like...
>
>         ASBIE Order Line. Line Item.  defined as "information directly
>         relating to a line item of a transaction. It identifies the
>         item but only includes details about the item that are
>         pertinent  to one occurrence on a line item, e.g. quantity etc."
>
>         ASBIE Order Line. Seller Proposed_ Substitute Line Item.
>          defined as "the item(s) that the seller proposes for the
>         substitution - the original ordered quantity, pricing etc,
>         which may be different from the substituted item. It is
>         assumed that hazard and shipment details etc will be the same."
>
>         ASBIE Order Line. Seller Substituted_  Line Item.     defined
>         as "item(s) replaced by the seller - the original ordered
>         quantity, pricing etc which may be different from the
>         substituted item. It is assumed that hazard and shipment
>         details etc will be the same."
>         and
>         ASBIE Order Line. Buyer Proposed_ Substitute Line Item.
>          defined as "alternative item(s) acceptable to the buyer -
>         quantity, pricing etc which may be different from the
>         preferred item. It is assumed that hazard and shipment details
>         etc will be the same."
>
>         Al  these are re-uses of LineItem. Details.  All have
>         defintions that relate to their re-use.  None require any
>         qualification of the object class.  The qualification is of
>         the property term (in other words the target object class) of
>         the ASBIE.  The EDIFIX view  you attached is not showing the
>         correct definitions.
>
>         Saito-san's question is not related to definitions - it is
>         terminology.  elsewhere  we refer to seller party but in one
>         place we use the term customer - clearly this was an oversight
>         and re-inforces the need for a controlled vocabulary.
>
>         Michael Dill wrote:
>
>>Hi Anne, hi TC,
>>please let me propose to add the following comment for this item 18,2 of
>>Yukinori Saito:
>>Yukinori Saito wants to change 'customer' to 'seller party'. Behind this we
>>do have a very basic conceptual question. The definitions in question of
>>e.g. Line Item. Maximum_ Backorder. Quantity is defined in reusable 'Line
>>Item. Details'.
>>Line Item. Details is directly reused in four other ABIEs (see attached
>>*.doc file). The very basic definition as of the Reusable Library cannot
>>express the specific needs of these four reusages.
>>
>>IF UBL agrees that definitions shall be meaningful, THEN a place is needed
>>where these meaningful definitions shall be written. The current structure
>>of the spreadsheets does not allow this, but CCTS does requires this, I
>>think.
>>
>>There are three or four ABIE needed, which base on 'Line Item. Details'.
>>These ABIE should restrict the underlying one and can have more specific
>>definitions due to the specifis usage.
>>
>>In such a case, they need an Object Class Term Qualifier.IMHO this is what
>>Mark also mentioned in one of his emails.
>>
>>
>>Best regards,
>>Michael
>>  
>>
>>------------------------------------------------------------------------
>>
>>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/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]