[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-lcsc] pre-draft model for appraisal and initial change log
Hi, Although not the official minute-taker, I did take notes. Here is what I noted (between dashed lines) from the end of the conversation on how to satisfy both the TBG17 requirements and the need to keep the UBL format as well: ---------- Tim: We want 2 spreadsheets, one which looks like current ubl document spreadsheets and the other looks like tbg17, and what happens is that when we change a value (name) within the ubl ss the name gets changed in the tng17 ss. The UBL spreadsheet is the master and used to calculate the tbg17 spreadsheet. Adopt tng17 macro for den naming. Michael: if we generate schemas from edifix models, edifix acn generate both ss formats. but not interested in this w/r/t gernating schemas. just presentation, except for still these issues: - issues already sent out ealier in email - proposal for combining 2 columns (property term possessive, property term noun?) - like to have discussion about rep term and rep term qualifier to identify qualified and unqualified datatypes; strongly linked to code list other things can be worked, just ened this. Tim: ok, so whatever we do with the ubl ss, micheals tool siwth gereate schemas and the tbng17 using using the rules. so we now realize that the data captured for edifix will have to be still in the ulb ss. that is what you (Michael) load up to create your data model Michael: provided they are fixed to provide what I need; and have to clear the conceptrual issues. Tim: Yes, ok, so the process will be that stephen continues to maintain ss in the way we have - it doesn't matter to us if we use tbg17 macro or not, because it won't be used for either our tbg17 submsisions or our rleease; we dn't need to worry about whether our ss calculates the right den. we should try, but it's mainly documenatary. the point is that the edifix program generates 2 outputs: ubl schemas and tbg17 submission. we don't need to do any more. we will continue to use the format we used in 1.0 beta and give Micheal new upadted bbies and abies (in ubl ss) that Michael can use to update the edifix model? Michael: yes, except for poperty terms and clear conceptual understanding about rep term and rep term qualifier. Tim: ok, so once we solve these questions, can use the existing ubl format? Michael: yes. Tim: OK, Done. -------------------- I'll send the full transcript to Tim and Stephen to see if they can sort out the changes Stephen was to make, and Tim can put this into more formal minutes, but my understanding was also as Tim has described in the email below, although perhaps it's better for us to do those fiddly edits to the UBL spreadsheets by hand at this point rather than try to generate that UBL ss base from edifix since Micheal has enough to do working on the internal edifix model and generating the tbg 17 ss and schemas? -Anne Tim McGrath wrote: > i am not sure this need be that complicated. > > my understanding of what Michel explained on tuesday is that he takes > the UBL spreadsheet(s) and loads them into EDIFIX. This gives him a > database of UBL BIEs. From this he can generate TBG17 spreadsheets > and also XSD schema (as per NDR rules). > > So our editing cycle should be..... > > 1. maintain spreadsheets (as we always have done). > 2. Load into EDIFIX and > 3. EDIFIX generates UBL Names and Dictionary Entry Names and does > integrity checks (which may require going back to (1.)) > 4. EDIFIX generates schemas . it can also generate any TBG17 > submissions - but we have already done this! > > The only variation on this is that because of the large number of > fiddly edits (such as leading or trailing spaces in some names), it is > easier for us (just to start the cycle) to use the EDIFIX database to > create a UBL spreadsheet as our initial base. This UBL spreadsheet > then becomes the maintenance format for our future modeling. > > The question i have is why does this have to change from what we have > always used? We do not need TBG17 (or any other formats) in our > maintenance model. EDIFIX will generate them as required. > > > > > Stephen Green wrote: > >> As a P.S. to my previous message, I'd add that beacuse of the obvious >> large size of the spreadsheets >> (include effectively three models copies in one sheet) I think we'd >> best *not* publish these like this in our package. >> (Not everyone has the bandwidth yet.) >> We could just strip them back to the same format as published in the >> beta but provide the larger spreadsheets somehow for >> implementers who need to see the changes from beta to final release >> more easily (along with the TBG17 submission data) >> >> All the best >> >> Steve >> >> One might of course >> just use this side-by-side structure for pre-submission >> maintenance and delete the TBG17 columns, after copying their >> contents >> (as strings) into another spreadsheet for submission, before >> publishing the former as UBL without the TBG17 side. >> > >-- >regards >tim mcgrath >phone: +618 93352228 >postal: po box 1289 fremantle western australia 6160 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]