[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of Atlantic UBL TC call 20 July 2005
MINUTES OF ATLANTIC UBL TC MEETING 15H00 - 17H00 UTC WEDNESDAY 20 JULY 2005 ATTENDANCE Jon Bosak (chair) Marty Burns Tony Coates Mavis Cournane Mark Crawford Mike Grimley Betty Harvey Anne Hendry Sue Probert Paul Thorpe STANDING ITEMS Additions to the calendar (http://ibiblio.org/bosak/ubl/calendar.htm) None. Liaison reports None. Subcommittee reports See Pacific call. Team reports See Pacific call. Regarding code lists: MB: still looking for resolution on Marty/Tony issue... Mavis/MG: Looked at the email; our understanding is the TC wanted to separate things out and you didn't. We agreed with your approach; this was captured in the minutes. AGREED that Marty should move ahead with the common approach. Review of Pacific and Europe/Asia calls No comments. DISCUSSION OF SUBSTITUTION GROUPS JB: Thanks to Stephen, Mark, Tony, and Marty for a very helpful email discussion. If we could have this kind of preliminary examination of all our difficult issues, it would make deciding them a lot easier. Here's my take on this one based on what's been said so far. We appear to have two issues: - Use of subsitution groups for customization of document schemas and code list schemas - Use of subsitution groups for minor versioning (and note that the question of whether to include version info in the namespace is not an issue right now, though it will be when we design a minor versioning methodology, so we should either hold that issue for later or continue the discussion under a different subject line) Regarding the use of subsitution groups for customization: Stephen and Tony have made some very good points regarding the difficulty of documenting and testing changes to the schemas without the use of a formal method like substitution groups. On the other hand, I think that Mark is correct in pointing out that there's no need for substitution groups in the major version schemas that *we* release. So I think that our goal should be to make sure that 2.0 is engineered in a way that allows others to use subsitution groups to modify the standard schemas; and we appear to have done this in making everything global. So I agree completely with Marty's last note on this: When a user community needs to extend or restrict UBL for their own reasons, it is desirable to use a mechanism that forces the implementer to declare the extensions explicitly. Substitution groups does this because in order to validate an instance the definition of the substituting type must be present. Also, the designer of the base schemas ensures the type consistency of the substitutable information. I believe what is being proposed is not that substitution groups are necessarily used extensively within UBL schemas. What is being proposed is that the schemas be designed so that the substitution group mechanism can be utilized in extending the schemas in a clean and traceable way (that is the extensions are explicit in the referenced schema in the instance document). If substitution groups are used in UBL schemas they would only need to be used in the code list schemas themselves to allow an unconstrained or enumeration constrained set of values to be used in the code list. What this requires of UBL primarily is the extensive use of global elements (the ones that are substitutable), and, code list schema design and usage that facilitates the extension mechanism. (from which I assume that we will not be using subsitution groups directly in either our normative document schemas or our normative code list schemas). Regarding the use of subsitution groups for minor versioning, in this case we are the customizers, and we need to discuss whether to use subsitution groups ourselves in making minor versions, but that discussion belongs to the time when we design a minor versioning methodology; again, I think our primary goal in 2.0 should be to ensure that we can use this approach if we want to. So to sum up, I think we should adopt as a design principle that everything we release should be substitution-group friendly in order to allow the use of substitution groups in customization and possibly in minor versioning. (Polling the group) MB: I support this view, but there may be a technical challenge if there are no substitution groups in code list schemas. Substitution groups require that you substitute something of the same type. So there may be a need for the code list itself to be represented as an unconstrained normalized string with a substitutable actual list in order to please the various parsers. This is a technical question we need to resolve; we might find that in order to make code lists substitutable, we have to have one substitution group in the code list. But we will avoid this if possible. MG: Agree with JB. There are two separate issues, and minor versioning can be dealt with when we get to it. For now, we must make sure that we don't do anything to preclude use of substition groups in the future. BH: Comfortable with whatever the group decides. AH: What MB is saying makes sense. We need to architect so that substition groups can be used if needed in the future. I would expect to see them used with code lists first. PT: Agree with Mark and JB about not needing substition groups in the schemas we publish. But we wanted code lists to be published and maintained by external organizations; how would this work with substition groups? JB: We want to engineer our schemas so that they can do that. PT: How does an implementation know that codes have been added? MB: Two ways: 1. You have a business process by which you will knowingly accept updates. 2. If you want to accommodate the revised code list without updating the schemas, you can provide a parallel exension until such time as you incorporate an update from the code list provider. Mark: If we are substition-group free in UBL 2.0 then I am fine with this. JB: Note the unresolved technical question raised by MB. We need to determine whether a substition group is required in a code list as published in order for the user to extend it. TC: We need to assure ourselves that people will be able to use the substition group without some hook. We need an example. AGREED to adopt a design principle that a customizer should be able to use substition groups as part of the customization process. ACTION: Code list team to investigate whether it is necessary for us to embed substition groups in code lists in order for a customizer to extend the code lists. ACTION ITEM REVIEW PENDING ACTION: JonB to revise the FAQ linked from the UBL TC page. Status: Still pending. [This is now a work item for Ottawa.] OTHER BUSINESS Mark: LMI can host the UBL meeting now scheduled for the week of 23 January. JB: We will discuss the meeting schedule in Ottawa, but that would make a good default. It certainly works for me. MB: Do we have a reference set of XSD validators that we expect instances and schemas to pass without errors or warnings? Mark: Jessica tested 1.0 against five validators. MB/JB: We could use this information. Mark: Robin Cover announced that NIST has made available a tester against multiple validators. AGREED that we will try out the NIST suite for validation tests. NDR WORK SESSION We discussed the three requests from Bryan. 1. A reconsideration of our prohibition of XSD ANY, because there are regional laws requiring the inclusion of specific information, and we need an extensible content area to handle this. AGREED that since Bryan's schemas will almost certainly be customizations, the inclusion of this data should be part of the customization. As a separate issue, we need to decide whether ANY should be allowed in conformant customizations themselves. 2. Restrictions on strings in UBL content to ensure that the content consists of more than white space, for example through length or minlength facets. AGREED that this level of data checking belongs to the application. Mark (tangentially): If we adopt ATG UDT, then we are no longer importing the CC parameter schema module into the UDT. We should drop the CC parameter schema mudule; it's just trying to specify what goes into annotation documentation and doesn't get validated anyway. 3. Reconsideration of our prohibition of appinfo, because there are many cases where one element is conditional on another; this would give Scehamatron (for example) the data it needs to do conditional/contextual validation. AGREED that the question of whether to include appinfo belongs to customization. Mark: We need to get Schematron into our customization methodology. Perhaps Rick Jelliffe can help us with this. NEXT WEEK Mostly code lists. Jon Bosak Chair, OASIS UBL TC
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]