Thanks Tim. You made my day man. You'll have to axe Arofan re: the SQUIRT thingie -- I think it's still a bit hush-hush. Seriously, it was my understanding that it was to be a separate kind of meta-object class (in addition to e.g. BIE, ABIE, BBIE, RT) that would denote any type suitable for use as a content component or supplementary component. That's precisely what "PrimitiveType" in the CCTS 1.8 feedback metamodel does/is. I see your metamodel, and yes I see the correspondence between your {BIE, BBIE, Data Type} and the feedback doc's {CC, BCC, PrimitiveType}. So far, so good. As we stipulated in the original document -- it is immaterial whether we speak of {CC, BCC, ACC} or {BIE, BBIE, ABIE}. In my latest metamodel, I'm explicitly modeling content component and supplementary components. Turns out IMHO that UML was able to represent that with high fidelity, what with the association roles matching up nicely with our ISO-1197 "intuition" and all (note: I suggest we have a group therapy session at the next F2F for anyone who has achieved an intuitive understanding of that specification :-) Is your "DataType" meant to encompass both the content component and supplementary components? I get what you're saying about the necessity of facets and rules. I think we could add those using a "UML Profile" (hear me Dave C?!?). A UML Profile lets us attach metadata to our UML Model (profiles are supported by Rose and Argo/Poseidon UML) and let you "tunnel" data through to downstream tools. Here's what I'm thinking now: 1. I don't care whether we model {CC,BCC...} or {BIE,BBIE...} so long as we're consistent. Someone please choose though! 2. I feel like the model ought to reflect a CC/BIE being comprised of a directly associated PrimitiveType/DataType (again I don't care what we call it -- someone please choose soon). That directly associated object fills the content component role relative to the CC/BIE. 3. I think the model also ought to reflect that a CC/BIE has supplementary components and that since each of those has a (user-specified) role name (relative to the CC/BIE) that they be associated through what we called BCCProperty in the feedback doc (through you may want to change that name to BBIEProperty now). 4. Also I think we should capture the XML facet information using the standard UML Profile capability of our modeling tools. * this (facet) metadata may already be part of Dave Carlson's XSD UML Profile. If not, it's straightforward to add. * The facet metadata would be associated with the PrimitiveType/DataType. This brings up the issue (are you there Mike A.?) that this UML Profile (for XSD) would become part of the UML design deliverable for UBL. Thoughts? -Bill