[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes August 20 2003
Dear all please find attached the minutes for this week. Please send regrets for next week and look at the action items. Regards Mavis ----------------------------------------------------------- 1. Roll call and welcome by the chair (Mavis) Mavis Cournane Mike Grimley Jack Gager Eduardo Gutentag Sue Probert Jon Bosak Bill Burcham Stephen Green Lisa Seaburg quorum achieved. Regrets: Mikkel Hippe Bruin Jessica Glace Mark Crawford Tony Coates Regrets next week Eduardo Gutentag 2. Containership Doing containers automated Doing containers manually Not doing containers. LC are putting together samples and a position paper and says we will probably do it manually. EG: Are these rules we have developed lately. LS: Yes EG: 115c, and 115d makes no sense. LS: The rule that says everything goes in to a "Top" element breaks everything. EG: Manually building in containers does not make sense. It is dependent on cardinality which is already there. LS: They say the recursions get too deep. They are talking real life and we are talking theory. JB: I thought we came to a joint decision in Montreal. LS: Yes they were going to do that exercise and come back to us on it. Discussion will be Sept 9th and Sept 10th jointly between LC and NDR. These will be Tues 8am PST, Wed 8:30am PST on the 9th and 10th Sept respectively. EG: I don't understand what 115c and 115d. [R 115c] The document element in the schema will have a content model that is a sequence of elements, the first of which will be the "Top" element, and the others will be the generated "List" elements, in the order in which their contained, repeatable children appeared in the model. SG: That defines the top elements. A and B is to define list. The problem was we had to come up with something that was auto-generated. Since then it was decided that human involvement was ok. A human needs to decide what is a list etc. The main thing is we already have some containers in the Model e.g. PartyName within we have Name which is 0 to many. If you had to add NameList or PartyNameList that just gets silly. That happens quite a few times. Only half of the possible lists needed to be manually created. There were other examples where it would be nonsensical to have a list. We would not want BBIEs to be multiple. We came to the conclusion in Montreal not to have automatic rule. EG: Why discuss it then? SG: The other half of the problem is that we have not looked at the other possible containers. Now we decided we can do them manually there aer alot of possibilities for other containers. AUtomatically, we could only have one container. Now we can look at grouping things together. We could have a head container that puts all the common elements in a document together. EG: The purpose of the joint meeting is to figure out how they can be replaced by human implementable rules. JB: I am not sure LC understand that we are not going to tackle this automatically. We may need to convey this to LC MHC: Lisa Seaburg will need to relay this to them. [R 115a] All non-repeatable BIEs that are direct children of the document-levelBIE in the model will be child elements of a generated "Top" element in the schema. The generated "Top" element will be named "[doctype]Top", and its content model will be a sequence. It will reference a generated type named"[doctype]TopType". Both the generated "Top" element and its type will be declared in the same namespace as the document-level element. (Note: This rule implies that all documents will have generated "Top" elements, without exception, regardless of their other 'body' contents, to cover cases where the document will be extended with the Context mechanism, and for general consistency.) [R 115b] All repeatable BIEs in the model will have generated containers. The containers will be named "[name_of_repeatable_element]List". These containers will be required if the cardinality of their contained immediate children requires at least one; if their contained children are optional;the container itself will be optional. At least one of the repeatable children of the List will always be required, but there may be more than one required child if that agrees with the cardinality found in the businessmodel.All "_____List" elements will reference a "_______ListType", which will be declared in the same namespace as the element that represents the repeatable BIE in the business model. The content model of this type will have a single child element, which will have a maximum occurrence that reflects the maximum occurrence in the business model, and a minimum occurrence as described in this rule, above.(NOTE: This rule applies equally to 'list' containers at the document level,and also at lower levels within the document.) [R 115d] All elements in the generated schema that are direct children of the generated "top" elements in all documents should be gathered together into a common aggregate type, named "TopType", which will be declared in the CommonAggregate Types namespace. This type should be declared abstract, and all document headers should be extensions - even if only trivial extensions to facilitate re-naming - of this abstract type. (Note: This rule allows for polymorphic processing of the set of generic header elements across all document types.) 3. Review of stuff that requires possible rules e.g Use of built-in schema attributes for elements not already addressed including abstract, block, default, final, fixed, form, maxOccurs, minOccurs - Use of built-in schema attribute 'abstract' for complexTypes LS: They are all part of attributes for the UR schema. SG: The idea of the UR schema means you need to support the abstract types. We don't expect them to appear in 1.0. will these rules only apply to LC and do we need extra rules for customisation. EG: The ur schema is a concept not a delieverable. Library will deliver the real schema and not the UR schema. SG: Ur would be derived by a rule so you just need to deliver the rule. Are we going to have to provide NDR rules for customisation. SP: We talked about Eduardo's guidelines. EG: These are not rule-based. EG: The difference between the real schema and ur schema is that whenever the schema has things that are not optional, the ur schema has them optional. All complex types in the ur schema complex. MHC: Are we clear that we are not delivering an ur-schema. EG: My inclination is to delete this and to delete rule 109 ALL: Agreed with quorum. Use of Instance attributes nil, noNamespaceSchemaLocation, schema Location, type Guidelines for use of All, Sequence, and Choice Done see rules 16 Use of extension element restrictions on introduction of elements and/or attributes in complexContent EG: That relates to CM and was introduced at some point by Dan Vint. There is little context here. Use of 'field' to specify XPath note Use of 'import' and 'include' EG: That may relate to CM. LS: It also comes in to codelists. EG: What does this mean? LS: The last time we discussed this we said it would be CM. MHC: We should say that possible rules will evolve naturally with the development of CM. ALL: Agreed Use of 'notation' Rule exists 114 Use of 'redefine' EG: I don't see why LC can't use redefine. Our issue with it was namespace. I can't think why they would want to use it, but we should not stop them? A rule for redefine is not required for UBL 1.0 as we will not be covering rules for customisation in the NDR rules for 1.0. Use of 'restriction' in simple types, in complex types using simple content, in complex types using complex content. A rule for redefine is not required for UBL 1.0 as we will not be covering rules for customisation in the NDR rules for 1.0. Agreed with quorum Use of 'schema' (parent element) attributes attributeFormDefault, blockDefault, elementFormDefault, finalDefault, targetNamespace, version, xml:lang EG: If the US government mandates that in all schemas they use must have the version attribute then we have a problem. If they don't then we don't have a problem. There are very few versions that have a version. MHC: We need to investigate this. ACTION ITEM: Mark Crawford to investigate if version is mandated on all schemas used by the government whether their own or external ones. Lisa Seaburg says that they are mandating this. EG: You can't add a version attribute without changing the UBL namespace. SG: I am guessing that such rules would not apply to external schemas. EG: I would not talk about xml:lang that is an XML thing. xml:lang is an xml feature not an XSD feature. For XML features we don't need rules. Agreed with quorum. attributeFormDefault SG: LC would value some input, should it be elements qualified, attributes unqualified by default. At the moment the schemas look bloated. Without the rule for elements you have to pre-fix every element. ACTION: SG to ask Chai-Kai for use case and a proposal for what is wanted. blockDefault MHC: We need an example and will ask Tony Coates if he wants anything for this. Use of 'selector' This is part of Key/Keyref and needed for it. Already covered by implication Use of 'simpleType' 'final' attribute LS: This is out of scope as we are not using substitution groups at this point. Any restrictions on the use of 'union' technique and its 'memberTypes' attribute There is a guideline for this in codelists but under normal use it is prohibited. Rule 100 Use of 'unique' There was a decision with LC in London not to use unique id MHC: THis is customisation and out of scope.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]