[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Such change might not have much impact on tools so I'd be all for it, even at this stage (yet to ask SSC though). I expect time would be taken to create the 'CommonTransport' spreadsheet and then to decide on what is 'core' (I hope it would be with a view to comparison with TBG17 CCs to broaden the scope beyond just procurement and transport). In that time we might hope to decide how to represent these CCs in the schemas and how to base BIEs declared in schemas on them (through XSD derivation based on the CCs or just as declarations as now but with references to the underlying CCs in XSD documentation or even some other way). In the meantime, I'd imagine we'd need small changes to the schema design to rename the CommonAggregate Components and CommonBasicComponents to something with Procurement in the name (still splitting aggregates and basics?). Maybe we'd be adding Transport before 2.0 and therefore need schema modules with Transport in the name too. All this seems like small changes to me. Two questions: 1. Would we be seeking to either a) combine BBIEs and ABIEs in the same schemas? 2. Would we be adding individual BBIEs to the common and core spreadsheets (outside of ABIEs, that is document level BBIEs which are considered reusable or rather potentially 'common' or 'core'? These would require, at a guess, more substantive changes to tools for schema generation and perhaps also to implementation software but it might still be the time to consider it. A third question: 3. What timescale might all this happen over? I hope that the design would be that only CCs exist in the 'core' spreadsheet(s) and schema(s). Then the BIEs would all be in the 'common' files and new namespaces wouldn't be needed when something moves to 'core' since its BIEs wuld still be where they started and the instances would then be protected from changes. The main reason (apart from that it seems to me the way to implement CCTS) is that then CCs could be created and improved without the need for a new major release and so could be created more quickly than if we had to wait the time our user base would prefer there to be between major releases. Plus I think it is the case that we need all BIEs to be based on CCs so *all* BIEs should be declared *both* in A. either a document spreadsheet (and schema module) or common spreadsheet (and schema module) *and* B. in the core *but as CCs* (not BIEs) **** I think we can do this from day one and refine the CCs as we compare them with Transport BIEs and with TBG17 CCs (if that is still on the cards). We'd need decisions: #1. on how to represent the CCs in schemas (presumably a separate schema module(s) for core but whether to use derivation to base the BIEs on the CCs) #2. whether to add, for now, initial CCs to the 'CommonProcurementComponent' and (perhaps later as we progress) the 'CommonTransportComponent' spreadsheets and perhaps to the 'common...' schemas (perhaps we'd call them candidate CCs but have them expressed just to avoid having BIEs which aren't based visibly on CCs) with a view to moving them (without impacting on instances, hopefully, and hence in minor releases) to 'core' files over time. #3. how to say in the model which CC a BIE is based on (perhaps a CC in the same spreadsheet or perhaps one in another) #4. how to name a CC while avoiding name clashes with equivalent BIEs *** - Just my initial thoughts All the best Stephen Green ----- Original Message ----- From: <ytlee@cecid.hku.hk> To: <ubl@lists.oasis-open.org> Sent: Thursday, May 19, 2005 8:56 AM Subject: [ubl] Groups - UBL V2.0 Model Architecture (UBL V2.0 Model Architecture.doc) uploaded > I updated this document according to the comments received from Yukinori > Saito. I didn't change every "CCTS" to "ebXML CCTS" because those > paragraphs were quoted directly from the UBL CD cover note while I added > "ebXML Core Components Technical Specification" in brackets behind the > first appearance of "CCTS". I uploaded this document in MS Word format (as > Mark pointed this out) so that anyone of you can comment on it more easily. > > -- Mr Thomas Lee > > The document named UBL V2.0 Model Architecture (UBL V2.0 Model > Architecture.doc) has been submitted by Mr Thomas Lee to the OASIS > Universal Business Language (UBL) TC document repository. > > Document Description: > Proposed data model architecture for UBL 2.0 > > View Document Details: > http://www.oasis-open.org/apps/org/workgroup/ubl/document.php?document_id=12776 > > Download Document: > http://www.oasis-open.org/apps/org/workgroup/ubl/download.php/12776/UBL%20V2.0%20Model%20Architecture.doc > > > PLEASE NOTE: If the above links do not work for you, your email application > may be breaking the link into two pieces. You may be able to copy and paste > the entire link address into the address field of your web browser. > > -OASIS Open Administration >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]