This list is presented in raw form. Some of these examples may not be real use cases, and in other cases it is unclear how to handle a specific use case (e.g. what context driver or value to assign). The list will be extended and refined as the use cases are discussed, including adding new comments and examples to each valid use case and deleting non-use cases.
The applicability of the context methodology to real-world problems will benefit greatly from additional use cases, especially for context drivers not covered by the current list. Parties who have comments on the existing use cases or who are interested in submitting additional use cases should contact the UBL Context Methdology Subcommittee chair.
This document has been augmented with comments from the Barcelona Face-to-Face (March 18-22, 2002) and Conference Call (March 29, 2002).
2.
Description: Currency must be included in price for cross border transactions.
Context Driver: Geopolitical
Value: Country of buyer and seller differ
Comments:
This example does not seem to be relevant
Not necessarily a valid use case, but does suggest that context drivers must be able to identify cases where a transaction is local or crossborder. Not clear exactly which context driver to use, maybe context driver values need cardinality greater than one.]
3.
Description: Note of fiscal type is required in invoice header in Brazil
Context Driver: Geopolitical
Value: Brazil
Comments:
no need to declare a new global type - add a new element
of string type to the header (XSD derivation doable in this
case)
4.
Description: Some rules are applied only to European interactions but not to interactions inside Europe that are specific to certain countries.
Context Driver: Geopolitical
Value: European (but not individual European countries)
Comments:
this is not a use case
Suggests that the issue of hierarchical context driver values is relevant. Need to find a real example of this in order to confirm that it is really necessary.
5.
Description: In Australia every invoice has to contain an Australian business number of invoicing party
Context Driver: Geopolitical
Value: Australia
Comments:
XSD derivation would not work for cardinality change, but
one could be added at the end.
6.
Description: In automotive, the VIN number is part of product description. Some companies in manufacturing add GPS info to delivery information.
Context Driver: Industry Classification
Value: Automotive
Comments:
adds an elemt (VIN), or we're gutting name/address, but
derivation cannot be used.
7.
Description: For airlines, there is a carrier code, fare basis, flight number, originating city, destination city, number of stops, stopovers, service class, reservation number.
Context Driver: Industry Classification
Value: Air Travel
Comments:
field additions, plus name change (TAAT)
8.
Description: For lodging, there is a check-in date and check-out date, reservation number. For car rental there is check-out date, check-in date, number of miles driven, vehicle class, insurance, security deposit, vehicle registration number.
Context Driver: Industry Classification
Value: Lodging, Car Rental
Comments:
field additions, etc, same as 7
9.
Description: Payment reference number required in invoice header in Scandinavia.
Context Driver: Geopolitical
Value: Scandinavia or individual Scandinavian countries
Comments:
no need to declare a new global type - add a new element
of string type to the header (XSD derivation doable in this
case)
10.
Description: Tax exemption depends on project because some work is done for a public body and some work is done for a private company, so the tax information might not be required.
Context Driver: Official Constraints
Value:
Comments:
if it's change from required to optional, as it seems to be
the case, XSD derivation cannot apply.
Official Constraints modifying cardinality.
11.
Description: The contents of the bill of lading or way bill depends on mode of transport.
Context Driver:
Value:
Comments:
Same as mode of transport above? Not clear
More evidence of a possible new context driver -- Mode of Transport.
12.
Description: US government requires a government bill of lading in addition to the normal bill of lading.
Context Driver: Official Constraints
Value: US Government
Comments:
is it two different doctypes? Does not seem to apply here.
Not enough information
Application of context, but to the business process, not to the document format.
13.
Description: When an order request becomes an order, you must put in a buyer request number (optional becomes required).
Context Driver: Business Process
Value: Ordering
Comments:
typically it's either extension - or as a different doctype
Probably LC SC will create a separate OrderRequest document type, so this won't result from application of context rules.
14.
Description: Consolidating shipper consolidating on behalf of several forwarders, who are also shipping on behalf of several consonors, the info that is provided to the guy up the hierarchy has to be filtered from the info provided down the hierarchy. E.g.: cost of transport is provided to the supplier but not to the customer.
Context Driver:
Value:
Comments:
this use case does not affect the schema, just the
instances.
Might require cardinality changes based on Business Process Role.
15.
Description: When publishing catalog content, depending on whether you are the originator or the republisher, if you are a republisher, you need to include the manufacturer's part number as well as your own part number.
Context Driver: Business Process Role
Value: Originator or Republisher
Comments:
change of cardinality from opt to required. OK
Business Process Role
16.
Description: In Australia, customs make a distinction at a line item level: when the item is composed of products from other countries, each item must be included in a separate line item (e.g. 25 bales of cotton, some from India, some from Bangladesh, you would need 2 line items).
Context Driver: Geopolitical
Value: Australia
Comments:
Needs change of cardinality in country-of-origin in
lineitem to required - fine.
Or adding country-of-origin if it's not in the base line item type.
17.
Description: In the Czech Republic, tax summary must be included with 0, 5 and 22 tax rates and amounts.
Context Driver: Geopolitical
Value: Czech Republic
Comments:
restriction of tax rates; change of cardinality in tax
summary to required, may need addition of fields to tax
summary, restriction of allowable values in tax rates or
addition of three required sets of different rates, and may
need removal of required field. Cannot be done with XSD type
derivation.
18.
Description: For tax-reporting purposes you must report tax rate in EU.
Context Driver: Geopolitical
Value: Europe or an individual European country
Comments:
this is ambigous - it may be a cardinality issue (must, but
ok for XSD extension) or an extension issue (tax rate and
supporting information)
19.
Description: In Singapore, the government generates all PO numbers (maybe for imported goods only).
Context Driver: Geopolitical
Value: Singapore
Comments:
Cardinality issue again, but XSD derivation is ok
Another example where application-specific metadata might be relevant, additional validation constraints.
20.
Description: Certain items in PO line items (credit card name and address for UK and a number of EU countries) is private, has to be masked out when sent to a third party -- NEED FOR SOMETHING THAT'S THERE BUT MASKED
Context Driver: Geopolitical
Value: UK or some other EU countries
Comments:
not our domain - it's security
Might indicate the need to add some application-specific metadata based on context rules.
21.
Description: UK and ex-dominion countries, account name has superiority over number, in other countries the reverse is true (deciding which field is optional).
Context Driver: Geopolitical
Value: UK and ex-dominion countries
Comments:
change in cardinality - change at least one required to
optional
22.
Description: Host of examples around certifications (e.g. Bordeaux wine is actually Bordeaux), requirements vary by country.
Context Driver: Geopolitical
Value:
Comments:
straight extension by derivation (as far as we can figure
out)
23.
Description: When shipping goods to countries that America doesn't like (some acronym), certificate of origin is required (several cases, like to Arabia from Israel, vice versa, etc.).
Context Driver: Geopolitical
Value:
Comments:
change of cardinality but XSD derivation is possible
24.
Description: Transport of hazard goods required additional fields: chemical constitution in addition to product name, contact information (many others) in line item at different points in the document.
Context Driver: Product Classification
Value:
Comments:
it's actually more than in line items, it may be throughout
the schema. XSD extension to various types would be possible,
as well as extension at the end of the header. But it's not
clear whether this would be enough, as there may be choices
involved, and XSD does not add OR leaves.
The general point is valid, otherwise simple case of the Product Classification context driver.
25.
Description: Same for storage (but different set of fields), so relevant for inventory.
Context Driver: Product Classification
Value:
Comments:
same as 24
26.
Description: Some might apply only if its shipped at sea.
Context Driver:
Value:
Comments:
this is very similar to case 1, so can't use XSD extension
Might be missing a context driver here. Is the mode of shipment covered by Business Process?