RE: [ubl-ndrsc] Analysis of supplementary component problem

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

Eve/Team:

I half agree with Mike rawlins, and half not...

There is always the approach where you know a component is a component's
sub-component, make that clear in the name, and establish it as a sibling.
We inherited some attributes like this from the original designers of xCBL
2.0, and simply came up with a naming convention to reflect the similarity.

Take language, as an example. In fact (whether you use xml:lang or not) this
is a structured piece of data, as it contains a language code and a locale
code when used to fully designate a lnaguage. If you can't encapsulate this
in an element structure, a pair of attributes such as "language.code" and
"language.locale.code" can designate the fact that the two are related
(assuming you don't use the xml:lang way, and make everybody parse the
string).

If you wanted to make these real codes, so that you can validate with a
parser against an enumeration, however, you will end up with a huge flat
stack of attributes, with weird names. This is a good reason to revisit our
decision to only use attributes for supplementary components. I think we are
establishing a set of cases where we should allow element constructs at the
component level (in cases where they have sub-components), rather than let
ourselves be ruled by a hobgoblinish need for consistency.

Cheers,

Arofan

-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Friday, June 14, 2002 9:03 AM
To: mike@rawlinsecconsulting.com
Cc: ubl-ndrsc@lists.oasis-open.org
Subject: Re: [ubl-ndrsc] Analysis of supplementary component problem


Thanks for the comment, Mike.  That makes it sound as though our only 
choice is #3, with a *requirement* to say what the values are of the 
nested SuppComs.  But I worry that this could be tricky, and certainly 
should involve the LC SC.

It's probably easy in a lot of cases involving Language.Code, because if 
we satisfy this with the xml:lang attribute, then it has a known code 
list.  But what about if we need to add information about the code list 
from which a code list agency identifier was taken?  (I know this isn't 
a real SuppCom from CCTS, but we had two people in our most recent 
meeting say that, in practice, they need this field.)

Am I missing something?  And can *all* the folks on this list who are 
involved in developing the CCTS please weigh in on this matter before I 
send my ravings to an official CC list? :-)

Thanks,

	Eve

Michael C. Rawlins wrote:
> Actually, I think the problem is much simpler than you lay out here.
> According to the ebXML CC spec, subcomponents are the lowest level 
> and don't have subcomponents.  However, I can certainly see how you 
> could get the impression below from reading the spec, and this is 
> one of the points I made when discussing my comments with the editors 
> last week. I strongly urge you to forward this directly to Mark Crawford 
> and the rest of the editing team to underscore the need to do something 
> about the relationship between Representation Terms and Core Component 
> Types.
> 
> Cheers,
> 
> Mike

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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>