[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: UBL NDR SC Minutes July 2 2003
Dear all please find attached a copy of today's minutes. If there are any corrections to these please provide them to me within 5 days, otherwise if no objections are raised these will be automatically approved then. Regards Mavis Co-chair ---------------------------------------------------------------------------- ---------------------- UBL NDR SC Minutes July 2 2003 Present: Danny Vint Mavis Cournane jack gager Sue Probert Anthony Coates Stephen Green Arofan Gregory Lisa Seaburg Mark Crawford J Glace Paul Thorpe Gunther Stuhec bill burcham Jon Bosak anne hendry Michael Grimley quorum achieved. Discussion items: 1. Containership 2. Namespaces 3. AOB 1. Containership AH - In LCSC yesterday it was agreed Arofan, Stephen and Tony would take this offline and resolve the question. Tim drew up a terms of agreement to decide the scope. MC - Containers are an instance not a schema issue. TC - no the containers have to be in the instance as well. MC - In the schemas we only have to define a container element. TC - The container generation should be done automatically. MC - What the containers are is more an instance issue than a design issue. BB - The decision to use containers, which ones to use for a particular document is an instance issue. TC - I would call it a structure issue. MC - Is this really something for NDR or for LC? JB - Identify up front the lists for which containers are appropriate and you put those in the spreadsheet. I am puzzled by Chee-Kai's point if you need individually named containers or whether you have something more generic. If you are going to generate these things I don't see how you have any other option than an anonymous types. Oh, yes you came up with an algorithm for naming these things. DV - The thing with single name falls apart when you want to control what the content model is. That is where Chee Kai's model falls apart. JB - does anyone have a clear idea what container you would want identified that you could not see coming at design time. You should be able to look at the data model and say here we need a container. TC - what would be the ad hoc basis you would chose to have a container in one spot and not in others. Developers look for regularity. Why have container in one area and not another. DV - I could fall on either side of this discussion. JB - What is ad hoc? SP - It is a business decision - it is not ad hoc. It is whether something that can be a rule or not given a particular document. SG - The one to many rule is a compromise. Really, you want it to be something that human being says these elements are grouped together. Chee Kai balks at this. You are creating an artificial rule based on the current content. If somebody messed with the cardinality someone would say this rule doesn't apply anymore. JB - you are saying the application of a mechanical rule happens to work for these particular cases but could go wildly wrong for the general case. BB - Nine months ago we decided it was not advisable to have a rule for container elements. We said that an Aggregate BIE is what the modelers would be used. There is precedence in DB design for at an analysis level for expressing associations with cardinality. At the LC level they would be expressing their constructs, the translation between that an XML we would either make the decision to have one to many expressed in lean XML or XML with extra container tags. It should be led by an example of how lean XML would break down. SG - Chee Kai did knock this down. I believe him. In my own development I have never used a container. I use schemas that do and don't have containers and I don't have any problems with schemas that don't have containers. JG - I think containers make things more logical. In some practical implementations there are complaints about overhead for processing. MC - Given that a subgroup has been asked to look at this are we comfortable at letting them work at this and come back to us on this. My thought on a general would be allow for containers and leave it up to the implementors. Is this really an NDR issue? BB - Some NDR people want to create a production rule to spit out container elements. JB - Shouldn't that be something for LC to go through this and decide what needs a container. AH - Let's look at Tim's email to see a clear description of what they are asking for. BB - We will solve 80% of problems if we get rid of the generation of containers. JB - The alternative is to create a list marker in the spreadsheet that is not an ABIE. BB - If it is not an ABIE I will have to expand the context stuff to deal with it. If it is an ABIE I can say the content of this thing is a recurring property BIE and later I can add 3 other attributes under where that pertains to everything in that list. SP - You will never have the concept of context for a container. TC - Where the container provides metadata that applies to all, that is something that cannot be auto-generated. The automatic generation only works in a global rule where you would not want to have any extra meta-data/ JB - The question seems to be - is there a way to auto-generate wrappers for repeating elements that is guaranteed to give you results that you won't barf over. If there is no guarantee when we through a wrapper we are saying these things are alike, and shouldn't it be up to the business people. AG - There was a long discussion on whether they were semantic things or not. We can do containers cleanly without making people barf too often. We are better having some containers we don't want than not having containers auto-generated. If the people creating the business models were optimizing the schema you would have no problems. That would be an implementation model which we have avoided up to now. The issue is getting a little clouded. JB - I am hearing that there is a layer of human judgement that does not belong to LC. AG - Maybe the LC people should be deciding which ones should have containers. JB - We are saying there is a design decision layer that is not a business one but is a sanitary layer. How about taking the current spreadsheet, a rule is applied that in 98% of cases produces the containers we would have generated on a case by case basis. Then we have a review process to look at the outcome. AG - My feeling, while that would be the best approach, I am not sure it is worth the effort. Stephen found only one case of something he was really unhappy with. JB: Arofan you and a group of people need to go off and do that level of specification. MC: As chair does anyone object to this approach of looking at our rules, specifying and coming back next week with something. Let's assume as there are no objections that NDR concurs. 2. Namespaces MC: We had a disagreement on how many namespaces we were going to create. LS: The last rule was a namespace per functional area not per document. I am happy to say we might have missed something. The rules were supposed to reflect the modnamver. AG: The rationale for functional areas, was the reuse of common thing. If what we are doing with our rules generation is to create two different sets of things, then the functional area nolonger makes sense. BB: On the functional area, my recollection we would define one namespace for each functional area, aggregate types etc. MC: I am getting a sense we are starting to question things that are not broken. LCSC are not in conformance with the rule, an LCSC person is espousing difficulty with the rule. Is our decision broken. AG: I think it is a forward looking one. TC: In looking at the instance documents some of the structures considered necessary are surprising. In LC they wanted to know whether we wanted to stand by our rules. MC: OUr message should be that we are standing by this. AG: They have not defined functional areas the way we had intended. MC: Maybe we should ask LC to give us back what these functional groupings should be so we can incorporate them. AG: We need to explain to them at what point is an aggregate common. BB: We are saying to LC is that there is a notion of package that you guys need to decide on. We should ask them to identify what package there thing is in. AG: We need to give them a hard rule. If something is not used in two functional areas it is not common. MC: These modules we are creating, which is some level of aggregation within the schema within a given functional areas, because these things are context dependent in fact BIEs are not going to be reused across multiple areas because they would be different BIEs. AG: You are talking about packaging a schema implementation of a business model. BB: I think we aren't adding a rule, more a clarification. They don't have to use the term namespace, they can have the concept of a package. AG: The activity you are suggesting aligns with business process within the notion of context. MC: Bill will you talk to Chee Kai with this. AG: The modelers should assign constructs to packages. These are related groups of document types that facilitate a business process. These are Common Aggregates, and functional areas. There are only 2 functional areas in V1. Anything used in more than one functional area is part of the Common Aggregates. SG: Is there a proposal here to recreate the reusable spreadsheet. SP: I hope not. BB: The proposal is to go in to the reusable spreadsheet and add a column to specify to which package does the component belong. 3. AOB 3. Regrets for next week Mark Crawford Arofan Gregory Mavis Cournane Sue Probert
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]