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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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


Subject: "VAT_Tax" Issue


At our 9/4 Registy TC Review of our work, Nikola raised an excellent
point regarding the automatic insertion of qualifiers for context. 

Up to now, we had been considering cases in which an entity is
associated with a single context category (in the creation of a BIE from
a CC), and we've said that the Object Class Qualifier and Property Term
Qualifier could be included as a Slot with each classification node. So
for example, if one were to create an ABIE from an ACC, they could
classify the ACC according to the "Geopolitical Context" context
category, "United States" node (for example), and the value "US_" would
be contained in a Slot included with the "United States" node that
represented the Object Class Qualifier (same for Property Term
Qualifier). Then, when the ABIE was created from the ACC, the value 
"US_" would automatically be copied into the Object Class Qualifier term
for the newly created ABIE. So, its name would begin with "US_" - for
example, "US_Address. Details".

This logic works fine for this single-context-category scenario, but it
breaks down when more than one context category is used. In the example
on p.21 of the CCTS spec, it states:

"An invoicing Business Process uses a piece of information such as
Invoice. VAT_ Tax. Amount.* Invoice. VAT_ Tax. Amount is a Basic
Business Information Entity that is based on the Basic Core Component of
Invoice. Tax. Amount. The invoicing Business Process is using Invoice.
Tax. Amount in a specific Business Context where the Business Process
Context = Purchasing, and the Geopolitical Context = EU. Therefore the
application of Context adds a specialised definition, but in all other
respects the Basic Business Information Entity is the same as the
associated Core Component of Invoice. Tax. Amount, i.e. it has the same
structure and Data type."

In the above example, 2 context categories (Business Process Context and
Geopolitical Context) are used. So how could a registry automatically
know to insert a Property Term Qualifier of "VAT_" when a BCC is
classified according to these 2 context categories?

I started thinking in automatic terms; I thought about the notion of
"Context Collections", in which an entity called a "Context Collection"
would "collect" these 2 context categories (i.e. it would have an
Association to each of them), and it would have one or more Slots to
indicate that a Property Term Qualifier of "VAT_" should be inserted
into the "Property Term Qualifier" attribute of any BBIE whose Property
Term value is "Tax".

But wait! We wouldn't want to have a rule for this...a user would want
to *create* this BBIE from the BCC. That is, the BBIE "Invoice. VAT_
Tax. Amount" should be created by a user as a result of their actions
through the UI of the registry. Or, it could be added using the Context
Constraints Language (reference p.69 of CCTS spec, the "Add" construct).

So in summary, I recommend that we retract our notion of including an
Object Class Qualifier and Property Term Qualifier with a classification
node, else we wind up trying to rewrite the Context Constraints
Language, and other Context mechanisms to come in the future (e.g. OASIS
CAM). We should leave it to these mechanisms to determine *how* the
values are placed in the various attributes.

Thanks,
Joe
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


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