MHonArc v2.5.2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ubl-ndrsc] Analysis of supplementary component problem
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC