Attendees: Tim McGrath, Lisa Seaburg, Mike Adcock, Marion Royal, Peter Yim, Bill Meadows, Bill Burcham, Monica Martin
Welcome and appointment of secretary to take minutes. - Lisa volunteered.
Release 0p70 -
Tim: To start off we will be looking at the Issues list V4p01 dated 5 November. I went through and added my comments and used color to designate groups of topics.. Starting from Tuesdays call, I have grouped the issues by types of issues. Things missing, things appearing, understanding, things we should fix, regardless.
The colors in the spreadsheet designate relationships and associations in the model.
Tim: If we look at the version 9 of the normalized components you will now see both sides of the associations.
Lisa: How do we know the difference between the parent association and the child?
Marion: One of the by products of the first round of doing this was doing the data analysis and I think we have captured that. This modeling is another valuable by product of this analysis and will be valuable to us.
Lisa: I see the value of this, I am wondering how we are going to get from this point back to a useable spreadsheet that we can actually build documents from.
Tim: I think we can do this from where we are. I accept the fact that there are some errors and mistakes in the making of this, and that we need to fix these.
Lisa: My fear or worry is how do we move forward from this point.
Tim: I am prepared to make the changes, edit this version to the document and go ahead and do the fixing.
Bill B: The problem we have now is translating what we have into the XSD spreadsheet without losing information.
Tim: Because there is this question, now that we have this wonderful model with everything we need, the assembly of components is feasible and in fact almost sort of a mechnical process.
Mike joined in late, we went through what we had just discussed.
Tim: The first issue we came up with is the idea that some of the associations had been inverted. I had thought that producing the version that had both ends of the associations in line them would help with this confusion.
Mike: Showing the associations were very confusing for everyone for that reason. It isn't clear which association is which.
Bill B: In UML they have the association end, so the green line is really the association end.
Tim: There is a pragmatic reason for doing this, putting them all in, by having them all there, it means when we assemble the document we can choose to delete the ones we don't want.
Bill B: Its when we do assembly that we do the one way street with the associations. I have a concern when I have my NDR hat on, I see the value of the modeling, but I have done some experimenting with XSD, it is difficult for me to figure out how we are going to capture this. Our default thinking is we what to end up with an XSD type for each one of these.
Tim: This becomes an issue when we start to assemble these documents. But even so, it is a decision that will be used to identify what a party looks like in a certain context.
Mike: What we need to document is the association direction. There needs to be a spreadsheet that will document how this works.
Tim: The version 0p70 is my attempt to show how that works.
Bill B: It is important that when we go from one to the other, when we have traversed an association, that we show how that was done and to show it as always the case.
Mike: Its one of the scenarios, we need to be able to show the relationship and direction.
Tim: What determines whether a structure is reusable is whether or not it is even reused. We look at the way Item has been implemented in Invoice and Order, we can ask, are these exactly the same in both contexts?
Mike: I am still concerned with the blue category with what is generalized and what is specialized. [This was about the disappearance of some of the components that had been in the last version of the spreadsheet, before the normalization process.]
Tim: Period for example, Period as I saw it was a structure to show a time period between two dates. We built this super structure that allowed us flexbility. Now when I went to my functional dependancy analysis I saw it as an optional between two types, so we ended up with no Period structure and instead ended up with just having the start date, end date.
Tim: I can see now that we may need some of these, we will have to rebuild these types of reusable types.
Mike: If we have them, it fits in better to Gunther's position on batches.
Tim: Where you have common sets of properties like Period and Measurement, this is similar to the building of super types that we had already been doing.
Bill B: I am thinking we can probably automate the translation of the normalized components into the UBL Library spreadsheet that becomes XSD.
Tim: Its a good idea and maybe in the future we can, but we aren't there yet, we are still hand crafting this work.
Tim: Do we see as the next steps is a verion 10 or the normalized components? And then move from there.
ACTION ITEM: We will move to version 10 of the normalized components document, Mike editing, Tim will work through the rest of the issues list, actually the two will work together on this. ACTION ITEM: Mike will send Lisa the indented list bits of work he has from Sue. The QA team will look at these tomorrow to see about building MIG type appendixs to the Scope Statement.
We will see how we stand at next Tuesday's meetings,
[I have to admit I missed quite a bit of today's dialog - it is very difficult to get all of the ideas going back and forth.]