[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).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]