[ubl-ndrsc] Analysis of supplementary component problem

["Eve L. Maler" <eve.maler@sun.com>]

This discharges an action item I took last week.  Actually, I suspect 
that this should be turned into a position paper, or rather, we should 
merge the elements vs. attributes and facets paper and add this info. 
(Gunther, what do you think?)

Essentially, we face more elements vs. attributes decisions because we 
haven't yet accounted for the supplementary components of supplementary 
components.  For brevity, I'm going to call supplementary components 
SuppComs, and (primary) content components ConComs.

*Problem statement:

According to our existing recommendation, something like the 
AmountCurrency.Identification.Code (a SuppCom of Amount.Type) should be 
an attribute on amount-related leaf elements.  But this currency 
identification info is of Code.Type, which has a slew of its own 
SuppComs.  So there are first-order SuppComms and second-order SuppComs 
in this picture, and XML won't let us put attributes (say, the 
second-order SuppCom related to the agency that owns the supplied 
currency code) on other attributes (the first-order SuppCom related to 
the currency code of the supplied amount).

*Analysis of the extent of the problem:

You can find the ConComs and SuppComs for all of the core component 
types on page 85 of CCTS V1.8, which is in the analysis input repository 
on the NDR portal:

   http://www.oasis-open.org/committees/ubl/ndrsc/input/

The document name is:

   Core Components TS Version OnepointEight.pdf

The second-order SuppComs are all of Code.Type, Identifier.Type, 
Text.Type, and UniformResourceIdentifier (huh?).  Of course, these 
*.Types have their own third-order SuppComs, and so on.  Luckily, 
however, Text.Type seems to bottom out at second-order, so the problem 
is really mostly with Code.Type and Identifier.Type.  (And who knows, 
maybe these will be combined in some future version of the CCTS. :-)

*A brief outline of some options:

1. Rescind our elem vs. att decision and make everything be elements
    Pro: elegant
    Con: extremely verbose

2. Add nth-order SuppCom attributes onto leaf elements
    Pro: compact
    Con: is it even practical? it would never bottom out

3. Fix the values of all the second-order SuppComs and forbid them
    from being supplied

    Pro: elegant
    Con: is it even possible?

3. Do a case-by-case analysis and design of each CCT, using subelements,
    additional attributes, and fixed and default values as desired

    Pro: tuned
    Con: time-consuming (though design patterns will likely pop up)

An additional complication is that we know the CCTS is incomplete; there 
are some useful supplementary components missing, such as the "code list 
from which the agency identifier of a code came", and probably also 
whole CCTs.

I suspect that option #3 is the one we'll have to pick, and we will 
probably have to consult with the LC SC in order to do it right 
(particularly around default/fixed things).  I fear that we'll also have 
to do some debugging of the original CCTs along the way.

Comments?

	Eve

-- 
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com