[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Outcomes of joint meeting Wednesday 2004.03.24
The coordination/joint subcommittee meeting Wednesday 24 March was attended by the following people: Jon Bosak Mark Crawford Michael Dill Stephen Green Michael Grimley Eduardo Gutentag David Kruppke Tim McGrath Monica Martin Sue Probert Marion Royal Lisa Seaburg Paul Thorpe The items listed in Tim's agenda for this meeting were disposed of as follows (all decisions were by consensus except number 19): A. Action Items for 9.2 schemas ------------------------------- 1) We are missing a required 'Version' element in the documentation of every data type. (We seem to be missing it in all the other schemas as well, for data types *and* BIEs.) Disposition: In our initial release, the version number is implied by the version number of the whole set (1.0), so there is no need to include the version number in the documentation for each data type right now. In 1.1, we will need to decide whether this is a registry requirement or a schema requirement. 2) There are some documentation elements whose names do not reflect those specified in the NDR: Occurrence, & ComponentType. should be Cardinality & CategoryCode Former AI: Tim - Occurrence to be changed to Cardinaility in models and CC Parameters Disposition: Done in draft 10. Remaining AI: NDR - CategoryCode to be changed to ComponentType in NDR. 3) In the CCT schema, the attribute definitions all declare 'use="optional"' even though it is the default value and does not need to be declared. In the UDT schema, 'use="optional"' is *not* declared (except in the restriction of 'cct:IndicatorType'). Do we want/need to be consistent here? Former AI: David - consistently, explicitly spell out 'use="optional"' Disposition: Done. 4) The documentation elements are not listed in the order specified in the NDR. Former AI: Mike G - change the order in cc parameter schema Former AI: David - recognize when building the schemas Disposition: Done, sent out. 5) We should have ccts:DataType in the documentation for each secondary representation term (e.g. Video has a data type of Binary Object. Type). It documents what the "base=" is. Former AI: David - populate data type of secondary rep terms with primary rep term. Disposition: Done. 6) Should have an import statement for UnspecialisedDatatypes to indicate this is where to get data types for any new types from. Former AI: David add import statement to top of schemas. Disposition: Done. 8) Confirm that the statement... <xsd:element name="CurrencyCode" type="CurrencyCodeType"> <xsd:annotation> <xsd:documentation>This element MUST be conveyed as the root element in any instance document based on this Schema expression</xsd:documentation> </xsd:annotation> </xsd:element> - is correct for each code list schema (obviously with the appropriate code list name). Former AI: David - don't include root element in code list schemas Disposition: Done. 10) We should have a ccts:DataTypeQualifer value for each code type (in the documentation). Former AI: David - populate in schema documentation. Disposition: Done. 11) Minimum and Maximum Temperature do not have a correct ccts:DataType (it says <ccts:DataType>. Type</ccts:DataType>) Former AI: Tim - remove definition of data type for ASBIE's in model. Disposition: Done (we shouldn't have data types on ASBIEs) -- spreadsheets now correct. 12) Document schemas should import Specialised Data Type schema Former AI: David - add import statement for Spec data type for all document schemas. Disposition: Done. 13) In the UDT schema, the 'DateTimeType' definition is what I would expect; there is a restriction on cct:DateTimeType that removes the infamous 'format' attribute. However, the datatypes with a base of 'cct:IndicatorType' or 'cct:NumericType' define a restriction, but then include the 'format' attribute, which in effect makes it no different than the CCT datatypes. Is this what was intended? Former AI: David - remove format attribute on UDT indicator type and numeric type (and those based on them) Discussion: We are trying to make sure that we are in compliance with the CCTS, but this is probably not necessary. All the supplementary components can be mapped onto XSD datatypes without breaking CCTS compliance. And if we are wrong about this and have to change later, it should not affect 1.0 instances. Disposition: Use XSD datatypes and document that in the UDT schema. New AI: Tim - provide the documentation. B. Open Items for Further Discussion ------------------------------------ 14) there seems no point in a /codelist directory. shouldn't these just be in '/common'? Disposition: Leave the current directory structure the way it is. 15) We only need cbcs for each "BBIE property" (PropertyTerm+Rep.Term) - not a cbc for each qualified BBIE. although i am then not sure how we can name any qualified BBIEs. Former AI: Mike G - research and give example(s) for discussion Wed. Related issue: should any elements be defined in document schemas or should all be in cbc.(was tim's issue 11.) Disposition: This was fixed in 9.2. 16A) Relative paths are being used for now to facilitate our validation (e.g. so we can review them without being connected to the internet). Discussion: The OASIS file structure cannot support absolute path names for schema modules. Disposition: Keep paths relative in 1.0 and revisit this in 1.1. Implied AI: Mark - Note this in NDR document. 16B) Vendor references in schemas. Discussion: There is a placeholder for vendor credits in the master document. Disposition: Remove "schema generated by GEFEG" etc. in final tweaks before balloting the CD, but keep until then; leave the date/time stamp in. New AI: David - Make this change. New AI: M. Dill - Review Appendix B.6 of the current draft of the master document and provide suitable GEFEG references and URL. See attachment to http://lists.oasis-open.org/archives/ubl-lcsc/200403/msg00044.html 17) There are modules created (CC parameters) that we don't define. Discussion: The purpose is to define a schema for the documentation, so if/when that is provided, it refers to this schema. We had this earlier, but is seems to have been inadvertently dropped. Everything is now the way it should be in the schemas, it just needs to be reflected in the NDRs and in the diagrams. AI: Tim: Provide a paragraph describing this module. AI: Mark: Revise NDR and diagram to reflect this. AI: Lisa: Update "schema modularity" to reflect this. 18) There are modules missing (UCTDT). Disposition: We are now in agreement on this. AI: Mark: Revise NDR and diagram to reflect this. AI: Lisa: Update "schema modularity" to reflect this. 19) There are empty modules (SDT despite specialised datatypes masquerading as unspecialised or changed CC types). Discussion: We agree on the following points: - A codelist is a specialized data type. - Each code list enumeration lives in its own schema module (per NDR). - We don't need CLUDT. We do not agree on whether it's better to import the codelist schema modules via the SDT module or directly into the aggregate schema and all the document schemas. I have not attempted to capture the pros and cons in these minutes. A poll showed that more people preferred to go with the schemas as currently constructed and sort this out in 1.1 than to revise the schemas again, so this was the outcome. But the decision was made simply to avoid another change to the schemas, not because we can clearly see one alternative as better than the other. Mark Crawford strongly disagrees with this decision and fears that there might be negative consequences for performance, but currently we have no data to resolve this matter one way or the other. Disposition: Keep the schemas the way they are and revisit this in 1.1. AI: Mark: Change the NDR document. Mark will investigate this further (particularly with regard to performance issues) to see whether he can support this in the CD. 20) There are elements declared that should not be (for cct and datatypes). Discussion: Global elements are declared for every type, but this is not required by NDR. Disposition: The global element declarations in CCT, UDT, SDT and CL modules need to be removed, and NDR needs to make clear that global elements are not required for those type definitions. AI: David - Make the change. 21) The code list schema modules are imported Directly into the cbc and cac modules rather than the UCTDT module, which causes circular import issues. Disposition: The udt code type should be replaced by xsd normalized string as the base type in every code list schema module. AI: David - Make the change. 22) The truncation rules are not applied consistently (see the cct supplementary components for an example). Disposition: Keep the current schemas the way they are. No change to NDR required. 23) The base types for almost all of the cct supplementary components have been changed in the cctmodule rather than creating specialised datatypes as we previously agreed to. Disposition: This is no longer an issue. C. Other Business. ------------------ 24) AI: Tim - Revised model and a change log of the revisions to David: Draft 10. 25) Question from JPLSC: http://lists.oasis-open.org/archives/ubl-lcsc/200403/msg00053.html Disposition: Add payment means as an ASBIE to Order, OrderChange, and OrderResponse (but not OrderResponseSimple).