Re: [ubl] Minutes of UBL Atlantic Call 13 October 2004

[Anne Hendry <anne.hendry@sun.com>]

Hi,

I just want to clarify, as I did in the call, that the first statement 
("From a single data model the tool would create spreadsheets and 
schema. These could be compared against other spreadsheets that would be 
created for QA purposes.") could be read to imply that the 'other' 
spreadsheets (the ones ubl is maintaining and using for business 
modeling) are maintainted solely for QA purposes.  As I noted in the 
call, this is almost the opposite of what we have discussed - the intent 
that we will be modeling ubl in, and maintaining, a set of spreadsheet 
outside of EDIFIX, then those are entered into EDIFIX and will produce 
secondary ss from it's internal model, and those EF secondary ss are the 
ones that will be used for QA purposes.  The difference between this and 
the above statement is that the EF-generated ss are the ones that are 
produced for QA purposes, and the 'other spreadsheets' are the ones we 
maintain and use for UBL business modeling, and represent the 'base' 
that should be tested against.  I think we need a better term for these 
than 'other' spreadsheets.

Along these lines, I'd like to propose a change in terminology   Since 
GEFEG uses the term 'data model' for it's internal model from which all 
outputs are generated (and now also quailfies this with 'UBL/CCTS'), and 
this has led to confusion because we also have been calling the 
spreadsheets the 'ubl model', that we adopt a clear and distinct term 
for the business models represented in the UBL hand-crafter 
spreadsheets.  This could be 'ubl business models, or 'ubl document 
assembly models' or anything else that is unique - anything but 'data 
models', or just plain 'models'.  In 1.0 we called them 'spreadsheet 
models' in the title of the section in the index.html file, and 
'spreadsheet assembly models' in the text.  'Spreadsheet model' is no 
longer a useful term as the output of EF, when it outputs ss, are also 
'spreadsheet models'.  I think we just need to agree on some terminology 
so we can get clarify in discussions on what it is we are talking about, 
and also in agreements, on what we are agreeing to.  Perhaps the models 
maintained and generated by ef should also be prefaced with 'ef'' 
(rather than, or in addition to,  'ubl') until we get this down.

I don't have any attachments to any of the terminology mentioned above, 
but jsut want to see two recognizably distinct terms used to refer to 
these distinct things.

-A

Mavis Cournane wrote:

> Dear all
> please find below an account of today's Atlantic call.
>
> Regards
> Mavis
>
> -------------------
> 1. Roll Call and welcome by Mavis the moderator.
> Attendees:
>
> Mavis Cournane
> Jon Bosak
> Marion Royal
> Jessica Glace
> Anne Hendry
> Tony Coates
> Sylvia Webb
> Paul Thorpe
> Marty Burns
>
> 2. EDIFIX DISCUSSION
>
> From a single data model the tool would create spreadsheets and 
> schema. These could be compared against other spreadsheets that would 
> be created for QA purposes.
>
> The spreadsheets would be imported into EDIFIX and it would use the 
> current UBL spreadsheet template for this purpose.
> The TBG17 template is also supported.
>
> There would need to be an alignment between the data in the 
> spreadsheets and what is needed to create consistent output.
>
> This alignment process would need to be discussed at the next face to 
> face.
>
> AH: We want to keep the spreadsheets as our modeling format.
>
> JB: The burden of compliance would be on the submitter. They would 
> need to submit in the agreed UBL template format.
>
> MB: In accepting submissions it is important to compare the input with 
> the EDIFIX output.
>
> JB: We will need to open up the EDIFIX black box to understand how it 
> works in order to get an understanding of what alignment will be needed.
>
> We should view this for now just in the context of 1.1 as we are 
> constrained with input spreadsheets as there is a mechanism then set 
> up for digesting these things.
>
> There are gating items:
> 1. We will have some work to make sure that the spreadsheet output 
> aligns with our spreadsheet input.
> 2. With regard to code list spec, there are some aspects of this that 
> need to be nailed down so that the tool handles code lists correctly.
>
> MB: Going to a model from XML is not a major issue for the tool. If 
> you kept your data model in XML and rendered the schemas based on the 
> data model, you could write an XSLT script to do the schemas.
>
> JB: Moving to the registry information model is something we would 
> want to look at beyond 1.1.
> I am not clear given the fact that the schemas we put out are 
> representations of our data model, I am not sure about the 
> distinction. Are these linearised and is GEFEG more complex? The model 
> that GEFEG is maintaining is something like the data model we have 
> before we create specific documents.
>
> AH: I think the GEFEG model has more in it than we can capture in the 
> spreadsheets.
>
> MB: Tony is proposing using XML for code lists and it makes little 
> sense to propose something different for this. One approach would be a 
> parallel one. The GEFEG tool is migrated along with the rules, the 
> codelists are progressed by Tony's vision and we evaluate in the near 
> term whether the method Tony has works.
> If you made it possible for submission to be in XML and you could 
> process it via XSLT or GEFEG you would have a forward looking approach.
>
> GEFEG could give us an idea of what the data model looks like when 
> they import it in to their too. Tony could build on that for the 
> specific ideas that he has for code lists.
>
> JB: That assumes someone has done the work on the XML realization of 
> the data model.
>
> MB: If that is something that could be provided in some format that 
> Tony could look at that would be great.
>
> ACTION ITEM: Sylvia will investigate if this could be made available 
> to Tony in some format.
>
> JB: Another big question is where does the resource come from to do 
> the work regardless of the tool.
> IF we accept this proposal we will have the work that generates the 
> schemas done for us by the tool.
>
> Is it understood that if we adopt this as tool the data model is still 
> the product of the UBL TC.
>
> SW: That is correct.
> With respect to EF being used for 1.1 only, has any thought been given 
> to what would be required to use it beyond 1.1?
>
> JB: The biggest impediment is that the internal data format is 
> proprietary and opaque. IF that were exposed and open everyone would 
> feel more comfortable.
> Assuming that the ebXML registry information model is perfectly 
> enabled, we would have the standard XML representation that Marty was 
> talking about, we would be more comfortable with EDIFIX. We would not 
> be single sourced then on the supplier.
>
> SW: Issues for us would be resources and cost.
>
> JB: I am really not making any assumptions what lies beyond 1.1 in 
> terms of this relationship.
>
>
> The critical issue is coming to a 1.1 issue of the code list spec, 
> until that happens we can't begin to create final versions of the code 
> list schemas.
>
> SW: We need to agree to what that spec is. The tool can populate the 
> schema with a code list and sub code lists or portions of a code list.
>
> JB: The way those code lists are used is controlled by wired in rules. 
> That part needs to be nailed down before any final schemas can be 
> generated.
> We will have a 1.1 code list spec doc, and at that point, let's assume 
> we have an EDIFIX guru to maintain the data model, that person won't 
> be able to make the changes to realise the code list model.
>
> SW: We won't reduce the tech support to maintain the tool, it is just 
> the data input resource that we are looking to reduce.
>
> JB: When the code list spec is final GEFEG will change the tool 
> accordingly.
>
> SW: We will fully maintain, enhance and update the tool.
>
> TC: To what degree do we need to use GEFEG to do the code lists.
>
> JB: My impression is that we saved alot of work around that by using 
> the fact that GEFEG has already built in the ordinary code lists. If 
> we provide these separately, we incur the job of maintaining that 
> representation.
>
> I think you are suggesting that we can provide codelists by a separate 
> process.
>
> We could move the completion of 1.1 code list spec out of the critical 
> path if we did late binding of the code list spec.
>
> The best strategy is to get early completion of a revised code list 
> spec and use EDIFIX. As a fallback plan we can provide by alternative 
> means these code lists schemas.
>
> If Tony and Marty look at this and conclude that there is a more 
> congenial way for them to work, then I would not have a problem with 
> that.
>
> SW: We would just like the final specs as quickly as possible.
>
> TC: In the long term I would like to see XML used. I don't have an 
> issue with the EDIFIX approach in the short term.
>
> Agreed: Tony and Marty will continue to work on the code list spec. 
> They will continue to work on the data model in XML format and will 
> liaise with GEFEG on how this could be implemented.
>
> JB: Unless something comes up in the Pacific Call I am inclined to 
> accept the proposal and I will probably put this to the TC in the 
> coming days. For 1.1 we have had a very good relationship. GEFEG have 
> been very accommodating and helpful, and we don't have many alternatives.
>
> AH: It would be good to have Tim talk to item 2 on the GEFEG proposal 
> regarding the CCTS spreadsheets.
>
> Agreed to change CCTS data model to CCTS/UBL data model in item 2 of 
> the GEFEG proposal.
>
>
> 3. STANDING ITEMS
>
>
>    Event reports
>
> Reviewed, nothing new added.
>
>    Liaison reports
> Done
>
>    HISC report
> Deferred. Jon did add that this SC is looking for members to provide 
> input.
>    [SSC report: covered as part of EDIFIX discussion]
>
>    Code List Team report
> TC: Input from SDML and MDDL has been received by Tony Coates.
> Tony is awaiting UBL input.
> Jon Bosak will check with Marty Burns if Tony takes team lead and 
> Marty continuing to be editor.
>
>    TBG17 Liaison Team report
> Done
>
> 4. OTHER ISSUES FOR DISCUSSION THIS MEETING
>
>    UBL FAQ: Status report (Anne Hendry)
>
> It was agreed that this would be worked on by the SSC for now.
>
>    UBL TC meeting in Santa Clara
>
> So far the following people have indicated they will be coming:
> Kim, Bill, Mavis, Anne, Jon, Eduardo, Sylvia, Peter Yim, Marion, Mike 
> Grimley.
>
>       Possible F2F agenda items:
>
> Reviewed.
>
>    Addition of new items to the work list
>
> Alignment will be added.
>
> We will not have a call the week before we meet in Santa Clara i.e. 27 
> October
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php. 
>
>