OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[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]