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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] UBL modeling question


Sorry, my use of variables let me down.  I should have said...

/In UBL, qualification of names applies when the structure of the BIEs 
are the same but the context of use is specialized.  So X_ B (meaning 
this is a qualification of B) would mean that if i opened up an X_ B it 
would have the same structure as an B.

If I added BIEs to B then i would not qualify the B.  The name is then a 
semantic/ontological decision.  It does not need to contain the term B 
at all.
/
Tim McGrath wrote:
> if i understand you correctly then the answer would be..
>
> In UBL, qualification of names applies when the structure of the BIEs 
> are the same but the context of use is specialized.  So X_ B (meaning 
> this is a qualification of X) would mean that if i opened up an X_ B 
> it would have the same structure as an X.
>
> If I added BIEs to X then i would not qualify the X.  The name is then 
> a semantic/ontological decision.  It does not need to contain the term 
> X at all.
>
> We have found this to be the simplest and most consistent way of 
> implementing the CCTS rules.
>
> So, in UBL we have Customer Party, this is not a qualification of 
> Party - but an extension (as you say).  It could have been called 
> Customer, but we felt including the term Party was helpful as it 
> indicated its major ingredients.  Some other uses of Party, such as 
> Freight Forwarder_ Party are exactly the same structure as Party, so 
> they are qualifications.
> Of course when the element names are created the distinction between 
> qualification and other terms disappears.  The difference is then that 
> CustomerParty is a CustomerPartyType and FreightForwarderParty is a 
> PartyType.
>
> CCTS does not allow nesting of qualifiers, but that is OK because the 
> idea of 'further qualification' does not really apply.  Obviously you 
> can qualify Customer Party as Buyer_ Customer Party (as we do in 
> UBL).  If you wanted to qualify (further) Freight  Forwarder_ Party 
> you would really be just creating another qualification of Party.  
> Such as Destination Freight Forwarder_ Party.
> The question to address is whether the object you are modeling is 
> re-using an existing structure or creating something new.  Or to put 
> it another way, what 'type' do you want the object to have.
>
> Stephen Green wrote:
>> Say I did want to add an existing ABIE 'A' to another existing one, 'B'.
>> Say I wanted to allow for the possibility that it be further extended
>> so I wrap it in another custom ABIE 'XB' 'container' (as is done with
>> qualified 'Party' ABIEs in UBL 2 which contain the generic Party
>> ABIE in such a way that they extend the Party with specific BIEs
>> like the various 'AssignedAccountID's). How, according to CCTS,
>> would I name this new container 'XB' ABIE? Would I simply qualify
>> the contained 'B' ABIE or is that wrong since I am not strictly speaking
>> merely qulifying the contained 'B' ABIE but am naming a container
>> ABIE which associates more than just the 'B' ABIE with the container?
>> What would I call the 'XB' container ABIE which contains ABIE 'B'?
>> Would I further qualify it ('YXB') to name the resulting ASBIE within
>> ABIE 'A'?
>>
>> Sorry if the wording of this enquiry ends up being rather cryptic;
>> hopefully someone will understand what I'm asking. I think it is
>> very similar to the naming issues that must have been faced when
>> modelling the various uses of Party ABIE in the UBL documents.
>> ---
>> Stephen D Green
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
begin:vcard
fn:Tim McGrath
n:McGrath;Tim
org:Document Engineering Services Ltd.
email;internet:tim.mcgrath@documentengineeringservices.com
title:Managing Director
tel;work:+61 893352228
tel;cell:+61 438 352228
url:www.documentengineeringservices.com
version:2.1
end:vcard



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