[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-cmsc] Conference Call Minutes 19-DEC-01
UBL NDR SC and CM SC Joint Conference Call Minutes December 19, 2001 Role Call: Bill Burcham -- YES Doug Bunting -- YES Dave Carlson Mavis Cournane Mark Crawford -- YES (x:36) John Dumay -- YES Matt Gertner -- YES Jack Gager Arofan Gregory -- YES Eduardo Gutentag -- YES (x:25) Eve Maler -- YES Dale McKay -- YES Sue Probert -- YES Gunter Stuhec Mike Rawlins Ron Schuldt -- YES Agenda: Come to conclusions on any and all aspects relating to extensions. Minutes: Arofan says that Gunter has some further issues regarding tag naming that he wants to raise in the next call, before this is finalized. (He is on vacation and couldn't make the call.) Issue raised as to whether the extension paper should be officially transferred from the NDR SC to the CM SC. Decision to table this until the end of the call, to see if sufficient consensus has been reached to take this step. Arofan says that we should focus on specific issues with the goal of making sure that enough consensus exists for the CM SC to move forward on the extension issue. Arofan describes the main issue as relating to the potential decision to model components and documents as XSD files with metadata (in the appInfo tags) that describe context information. The context language should be expressed in XML and should transform the core schemas into business schemas. The big issue is subtractive refinement, because we know that no verifiably complete implementation of refinement exists today. There is also no means to distinguish between optional elements that can be removed and those that cannot. Matt restates this as determining to what extent we want to bind the extension mechanism to a specific schema language considering that we know that no schema language supports everything that we will need. It would therefore make sense to design the extension methodology using only features of the schema language relating to document structure (which tend to be very similar across all schema languages), and use schema annotations to describe all other aspects (context, derivation relationships, etc.). The decision of whether to use appInfo for the annotations should be discussed. Eve points out that the decision to use XSD for the modeling language has already been made. And this is orthogonal to the decision that Matt is now proposing. Arofan says that the Core Library SC is assuming use of XSD for modeling. General consensus that we have settled on XSD. Dale makes a supporting statement for Matt's proposal by pointing out that in his organization, programmers have tended to take this approach for practical reasons. Matt adds that sticking to the structural features of XSD will also eliminate a lot of the objections that people have to XSD. Arofan raises the issue of whether we should at least express the features for representing type relationships, since we feel that these relationships will be important, so we might as well use the features that are there. Matt objects because this will cause all the issues about, e.g. use of refinement, to rear their head again. Eve restates this with the following disjunct options: (1) Use none of the features of XSD. (2) Use the features of XSD when they are there, but use an ad hoc approach for things that are not supported by XSD. Matt insists that (2) would make us face the issue of refinement (and others). Arofan says that in his position paper, he is advocating a mechanism that lets you add things, and then refine things down, rather than settling for one or the other. Using a two-step process is not as messy, but it does dictate to people how they have to do processing. Eve says that this is the only way that makes sense. Arofan says that various industry groups are already considering this kind of approach. Eve thinks out loud: this would require that the extension mechanism let you remove stuff ONLY if it has already been added in the previous step (i.e. it's not built into the standard component). Arofan says that if we can agree on this, this is the key thing. Eve points out that the process currently proposed by v1.04 (the Vienna document) is not two-step. But this isn't really a problem. We all agree that this is not a finished work. Doug has just one question: in what cases does refinement come into play? Since we are talking about groups of core components that can be removed as needed, so where would refinement come into play for the individual components? Arofan and Matt point out that the components (and BIEs) are recursive, so they can contain component parts as well that might have to be refined out in certain contexts. Doug continues: he can see why removing components from a BIE (if you've added too much before), but that the core component should be truly core, so there wouldn't be need to remove anything. Arofan says that the CL SC is not defining minimal components, they are designing 80/20 components, so they contain a lot more than most people will need (implying that refinement will be needed). Doug argues that this might hamper interoperability, since some parties would not be using components that are needed in 80% of cases. Matt says that this might be a misrepresentation of the 80/20 rule, which really indicates that the optional elements might be needed, but the fact that they are really required will be determined by context. Arofan points out that there needs to be distinction between optional (and can be removed) and optional (and needs to be kept as optional). Ron gives the example where a supplier enterprise identifier might be needed. Some parties might just call this "enterprise identifier", while others might want to distinguish between "supplier enterprise identifier" and "manufacturer enterprise identifier". Arofan says, in essence, that this is an issue addressed by UBL but not necessarily by the context extension methodology. What is really relevant is whether, contextually speaking, a buyer id or whatever is required by a pair of trading partners. This can be enforced by having controlled vocabularies. In essence the problem raised by Ron will be solved by intelligent schema design inside the CL SC. Matt summarizes issues: (1) Should we depend on just the structural features of XSD and worry about what type derivation features we use later? (2) Do we accept Arofan's two-step process for extension (first extending and then refining)? (3) Do we need special optional elements that are either: (a) removable, (b) not removable and (maybe) (c) not allowed to be made required. Dale suggests that we just accept (2) for now, and then see if any issues that are raised as we work the use cases. All agree. Matt restates the problem of (1) (see above in this minutes document since it's already outlined). Arofan objects to the idea that the importance of type derivation information in the schema is proven to the extent that Commerce One has used it for some time to build software architectures. Doug raises some objections because processing apps might choke on derived types that are somehow not compatible with the base type. Arofan points out that optional fields really mean optional at design time, so by run-time we should know which information to expect. Eduardo says that the more Arofan argues his point, the more he feels that it would be very hard to take care of derivation relationships in real running code. Matt argues that we really don't have to worry about expression in schema about this point, that we should forge ahead with designing the context extension metholodgy and worry about this later. Arofan asks if anyone objects to this. No one speaks up so we are moving ahead with this assumption. Next Steps: Decision to hold next NDR SC call on January 2nd. Topics will be: (1) Tag structure (1st hour) (2) Modularity, naming and versioning A separate CM SC call will be planned. Meeting will be held at "normal" time (11am-1pm EST). Eve will send an agenda. Happy Holidays! ---------------------------------------------------------------- S C H E M A N T I X * TOMORROW'S SOLUTIONS TODAY Chief Executive Officer * www.schemantix.com ----------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC