[ubl-cmsc] Minutes of 29-MAR-02 Call

[Matthew Gertner <matthew.gertner@schemantix.com>]

Minutes from Conference Call 06/DEC/01

Attendees:
Bill Burcham
Matt Gertner
Eduardo Gutentag
Paul Thorpe

No quorum sought or achieved.

---

(1) TAAT, DWP and Paella issues

Higher level principle of DWP is that we want to have a derivation
relationship with the base schema whenever this is possible. Bill explains
that some problems resulted when this was discussed in more detail, leading
to the idea of Paella. One problem is that, if an Address occurs somewhere
in an Order, a modified Address causes the changes to cascade up the
hierarchy and requires specialization of the Order itself, if we want to
enforce use of the modified Address. The other issue is related to the old
problem in XSD derivation that you can only extend types with new elements
at the end of the content model, and you can't remove things.

The only way to solve the first problem with XSD appears to be to reimport
the type so that the standard UBL version of Address appears to be
different. This is accomplished using a special redefine function of XSD.
Matt asks why this is even a problem in the first place. It should actually
be considered as strictly correct that an Order be different from the
standard Order if it has a difference such as requiring a modified version
of an Address subelement. Matt suggest that it would be perfectly okay, and
in fact desirable, to redefine both Order and Address in a new namespace if
the Address is modified.

Bill explains the use case as being if a company needs to use a different
Address everywhere, but doesn't want to redefine every document type that
references Address. One conclusion could be that you can only create new
types, you can't "destroy" or replace existing types. Bill implies that
there might be some risk of "type explosion" if we create a whole bunch of
new Address types. Matt points out that ebXML solved this issue by storing
new types created through application of context rules in a repository and
retrieving them where appropriate, so that the new types really are global
and reusable.

Discussion leads to the issue of naming. If this approach is taken, then
it's unclear what to call the new types. Bill suggest that we either use a
different namespace for each new type, or we define the types in one
namespace. General consensus that the right and logical thing to do is to
state that every type has identity, enforced by its unique combination of a
namespace and type name, and that redefining the type without giving it new
identity is wrong. This, if accepted, will solve a lot of issues.

! Need to clarify that this conclusion would preclude of XSD redefine.

Eduardo complains about implication that all names in the hierarchy would
have to change to account for a change in the subelement, invalidating
XPaths. Bill and Matt contend that this would not break XPaths if the names
do not change (only the namespace). Eduardo asks what is the advantage over
TAAT in this case. Matt says that this provides additional info about the
relationship between the two schemas (namely that one is a specialization of
the other) that would be useful to a processing application.

Eduardo complains about the example where you might want to change the
cardinality of something from 1-6 to 0-5. This is not possible using normal
derivation, but would be possible using Paella (because there is an abstract
base type). Matt complains about Paella because there is no longer any
information conveyed by the base types, since they are empty. Bill suggests
that the schema references the abstract type, but the implementation is also
included in UBL and can be used for derivation. Eduardo is concerned about
the complexity of implementing a context rule engine based on this proposal.

---

(2) Review of use cases

New comments enclosed in [brackets]. Old comments transcribed by Eduardo are
preceded by >>,

1* Cellphones in Switzerland must be sent to personal address
         Region = Switzerland
         Product code = Cellphone
         Add personal address or make personal address required

 >> ship to address must be burst out into personal addresses
rule needed: derive a type from another and change the
cardinality of a child (number of addresses) -> transformation

[XSD derivation lets you change cardinality in one direction (restriction)
but not in the other. Matt suggests that one solution would be to have a
separate line item for each phone. But there is a more general case here
where XSD derivation doesn't provide the needed functionality, relating to
the discussion of (1) above.]

2* Requirement to have currency in price would depend on
whether it is a local or crossborder transaction -- WE NEED A
BETTER EXAMPLE

 >> 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* Europe has VAT associated with price, in US it is already
included

 >> Not clear what the problem is, not clear what the
requirement is.

[Another optional vs. required case.]

4* Note of fiscal type is required in invoice header in Brazil

 >>   no need to declare a new global type - add a new element
of string type to the header (XSD derivation doable in this
case)

5* Payment reference number required in invoice header in
Scandinavia

 >>   no need to declare a new global type - add a new element
of string type to the header (XSD derivation doable in this
case)

6* 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

 >> 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.]

7* Same for storage (but different set of fields), so relevant
for inventory

 >> ditto

8* Some might apply only if its shipped at sea

 >> 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?]

9* 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.)

 >> change of cardinality but XSD derivation is possible

10* Host of examples around certifications (e.g. Bordeaux wine
is actually Bordeaux), requirements vary by country

 >> straight extension by derivation (as far as we can figure
out)

11* UK and ex-dominion countries, account name has superiority
over number, in other countries the reverse is true (deciding
which field is optional)

 >> change in cardinality - change at least one required to
optional

12* 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

 >> not our domain - it's security
 
[Might indicate the need to add some application-specific metadata based on
context rules.]

13* In Singapore, the government generates all PO numbers
(maybe for imported goods only)

 >> Cardinality issue again, but XSD derivation is ok
 
[Another example where application-specific metadata might be relevant,
additional validation constraints.]

14* For tax-reporting purposes you must report tax rate in EU

 >> this is ambigous - it may be a cardinality issue (must, but
ok for XSD extension) or an extension issue (tax rate and
supporting information)

15* In the Czech Republic, tax summary must be included with
0, 5 and 22 tax rates and amounts

 >> 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.

16* 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)

 >> 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* 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

 >> change of cardinality from opt to required. OK
 
[Business Process Role]

18* 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

 >> this use case  does not affect the schema, just the
instances.

[Might require cardinality changes based on Business Process Role.]

19* When an order request becomes an order, you must put in a
buyer request number (optional becomes required)

 >> 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.]

20* US government requires a government bill of lading in
addition to the normal bill of lading

 >> 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.]

21* The contents of the bill of lading or way bill depends on
mode of transport

 >> Same as mode of transport above? Not clear
 
[More evidence of a possible new context driver -- Mode of Transport.]

22* 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

 >> if it's change from required to optional, as it seems to be
the case, XSD derivation cannot apply.

[Official Constraints modifying cardinality.]

23* 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

 >> field additions, plus name change (TAAT)

24* For airlines, there is a carrier code, fare basis, flight
number, originating city, destination city, number of stops,
stopovers, service class, reservation number

 >> field additions, etc, same as 23

25* In automotive, the VIN number is part of product
description. Some companies in manufacturing add GPS info to
delivery information.

 >> adds an elemt (VIN), or we're gutting name/address, but
derivation cannot be used.

26* In Australia every invoice has to contain an Australian
business number of invoicing party.

 >> XSD derivation would not work for cardinality change, but
one could be added at the end.

27* Some rule is applied only to Europe interactions but not
to interactions inside Europe that are specific to certain
countries

 >> 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.]