[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [ubl] Change requests for the next 1.0 schema generation
No, everyone is in agreement here: you, NDR, Mike Grimley, joint call members, Tim, etc. that we add back in 'format' to these types (that we do not mess with the cct types - we only change things in the udt and sdt/cl modules). Please look at the summary of the meeting notes that Tim sent out, which I've attached here again, for a complete list of decisions, and note that the removal of the restriction is noted in Issue 12. I'll go through the list and see if there's anything else missing from Stephen's previous email, but you and David should also review this summary yourselves to make sure you've included all the changes that say something like "David will fix", or something similar. Thanks, Anne Michael Dill wrote: > Ooooh, I seem to remember that the NDR discussion in Washington was > just the other way round and that the group disagreed with my 'simple' > CCTS approach. > Now, I'm confused. > Stephen: help > Michael > > > -----Ursprüngliche Nachricht----- > Von: Grimley Michael J NPRI [mailto:GrimleyMJ@Npt.NUWC.Navy.Mil] > Gesendet: Donnerstag, 18. März 2004 15:02 > An: ubl@lists.oasis-open.org > Betreff: RE: [ubl] Change requests for the next 1.0 schema generation > > Greetings, > > As mentioned in a previous email, and not included below, the > latest CCT schema still has 'DateTime', 'Indicator' and 'Numeric' > types defined as simple types (with a *Restriction* on the built > in type). > > I believe we had agreed in Washington that they would be redefined > to conform to the CCTS. That is, the required supplementary > component 'Format' would be added to the definition of each. > > I wasn't able to make yesterday's meeting (until the end, anyway) > and Jon has made it very clear that that is where the decisions > are made; however, this involves CCTS conformance and, if I am not > mistaken, the decision was made in joint session with Tim and > Steve on the phone, so there was good representation of all > concerned SCs. > > Thank You, > > Mike Grimley > > -----Original Message----- > From: Stephen Green [mailto:stephen_green@seventhproject.co.uk] > Sent: Wednesday, 17 March 2004 15 42 > To: ubl@lists.oasis-open.org > Subject: [ubl] Change requests for the next 1.0 schema generation > > Here is a list of the change requests just sent to David at > Gefeg for the next iteration of > UBL 1.0 Schema generation > > > > Changes Requested > > (1) The Codelist Schema Modules should be treated as being > Specialised DataType > Schema Modules. They are to remain as separate Codelist Schema > Modules but > the existing Specialised DataTypes Schema Module will no > longer be used to reference > the Codelist Schema Modules. Instead it will be almost empty > (similar to how it was in beta > as the 'DataTypes Schema Module'). I would predict it looking > like this (if it is generated for draft 8): > > <xsd:schema > targetNamespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4" > xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4" > xmlns="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4" > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > elementFormDefault="qualified" > attributeFormDefault="unqualified" version="1:0-draft-8.4"> > <xsd:import > namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4" > schemaLocation="UBL-CoreComponentParameters-1.0-draft-8.4.xsd"/> > </xsd:schema> > [with the usual UBL Header comment block too] > > or, if Tim releases his draft 9 very soon, like this: > > <xsd:schema > targetNamespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-9.1" > xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-9.1" > xmlns="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-9.1" > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > elementFormDefault="qualified" > attributeFormDefault="unqualified" version="1:0-draft-9.1"> > <xsd:import > namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-9.1" > schemaLocation="UBL-CoreComponentParameters-1.0-draft-9.1.xsd"/> > </xsd:schema> > > [In the following examples I'll just keep to the draft-8.4 > scenario.] > > > (2) This Specialised DataTypes Schema Module will only need > to be imported into the Common Basic Components Schema > Modules. > > This is because the Code and Identifier BBIEs are the only > ones declared outside of the CBC Schema and of these two types > the only relevant one is likely to be code which has its > specialised datatypes defined in the separate codelist schema > modules (a special type of SDT Schema) and not now in the > 'Specialised DataTypes Schema Module'. > > > > (3) The 'use' subfolder within the 'codelist' folder is to > be dropped and all the codelists schema modules just placed in > the 'codelist' folder > > > (4) With the change in the non-codelist SDT Schema Module in > (1) above, the other Schema Modules will > need to reference the Codelist Schema Modules directly, i.e.: > > targetNamespace="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0-draft-8.4" > xmlns:res="urn:oasis:names:tc:ubl:codelist:AcknowledgementResponseCode:1:0-draft-8.4" > ... > xmlns:cur="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-8.4" > xmlns:sdt="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4" > xmlns:udt="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-8.4" > xmlns:cbc="urn:oasis:names:tc:ubl:CommonBasicComponents:1:0-draft-8.4" > xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4" > xmlns="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0-draft-8.4" > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > elementFormDefault="qualified" > attributeFormDefault="unqualified" > version="1:0-draft-8.4"<xsd:import > namespace="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-8.4" > schemaLocation="../codelist/UBL-CodeList-CurrencyCode-1.0-draft-8.4.xsd"/> > ... > <xsd:import > namespace="urn:oasis:names:tc:ubl:codelist:AcknowledgementResponseCode:1:0-draft-8.4" > schemaLocation="../codelist/UBL-CodeList-AcknowledgementResponseCode-1.0-draft-8.4.xsd"/> > <xsd:import > namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4" > schemaLocation="UBL-CoreComponentParameters-1.0-draft-8.4.xsd"/> > <xsd:import > namespace="urn:oasis:names:tc:ubl:CommonBasicComponents:1:0-draft-8.4" > schemaLocation="UBL-CommonBasicComponents-1.0-draft-8.4.xsd"/> > <xsd:import > namespace="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-8.4" > schemaLocation="UBL-UnspecialisedDatatypes-1.0-draft-8.4.xsd"/> > > > (5) The mention of DerivedCodeType is to change to > xxxxxCodeType where xxxxx is the Property Term of the CodeList > e.g. cur:DerivedCodeType becomes cur:CurrencyCodeType > (in future, external groups might be defining their own names > for these codelist schema modules but we will stick to using > the property from the SDT model) > > > > (6) Note that since the Codelist Schema Modules are now > considered to be a kind of Specialised DataType Schema Module > and that the module > called the Specialised DataType Schema Module (of which in > future there could be many incidentally) is almost empty in > UBL 1.0, the reference > to the type of a code having a codelist schema module from > within the CommonAggregateComponents Schema Module or, where > required, > a Document Schema Module will look not like > sdt:DerivedCodeType or sdt:CurrencyCodeType but for the > example of the currency code like this: > > > <xsd:element name="CurrencyCode" type="cur:CurrencyCodeType" > minOccurs="0"> > <xsd:annotation> > <xsd:documentation> > ... > > > > (7) Not, I think, a change request but more a note: In beta, > the credits for codelist schemas defined in the codelist > spreadsheet (now the SDT spreadsheet) > were added to the UBL comment header block. Now they won't > appear at all in the Schemas (as, I believe they don't anyway) > but will just be held in the > spreadsheets. > > (8) Again, not a change request but a note, since you've > already started implementing it: The codes will all be based, > not on the cct:CodeType but on the > udt:CodeType (thanks) > > (9) The 'names' for codes from the codelists (the second > string from the code text file) should appear in some way in > annotation/documentation associated > with the 'value' enumeration in the Codelist Schema Module. > > e.g. > > <xsd:element name="CurrencyCode" type="CurrencyCodeType"/> > <xsd:complexType name="CurrencyCodeType"> > <xsd:annotation> > <xsd:documentation> > <ccts:Instance> > <ccts:Prefix>cur</ccts:Prefix> > <ccts:CodeListQualifier>ISO 4217</ccts:CodeListQualifier> > <ccts:CodeListAgency>6</ccts:CodeListAgency> > <ccts:CodeListVersion>0.3</ccts:CodeListVersion> > </ccts:Instance> > </xsd:documentation> > </xsd:annotation> > <xsd:simpleContent> > <xsd:restriction base="udt:CodeType"> > <xsd:enumeration value="ADP"> > > ... > <xsd:enumeration value="USD"> > <xsd:annotation> > <xsd:documentation> > <CodeName>United States Dollar</CodeName> > </xsd:documentation> > </xsd:annotation> > </xsd:enumeration> > > ... > > <xsd:attribute name="name" type="xsd:string" use="optional"/> > <xsd:attribute name="codeListID" > type="xsd:normalizedString" use="optional"/> > <xsd:attribute name="codeListAgencyID" > type="xsd:normalizedString" use="optional"/> > <xsd:attribute name="codeListAgencyName" type="xsd:string" > use="optional"/> > <xsd:attribute name="codeListName" type="xsd:string" > use="optional"/> > <xsd:attribute name="codeListVersionID" > type="xsd:normalizedString" use="optional"/> > <xsd:attribute name="codeListURI" type="xsd:anyURI" > use="optional"/> > <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI" > use="optional"/> > <xsd:attribute name="languageID" type="xsd:language" > use="optional"/> > </xsd:restriction> > </xsd:simpleContent> > </xsd:complexType> > > > I'm not sure in this example whether you'd use this same > element <CodeName> . In the CLSC example > an undefined prefix is hinted at but I think we have yet to > see how things turn out with the issues around > the use of the Core Components Parameters Schema Module - > whether an element defined there might > be suitable. For now I'd suggest sticking with <CodeName> > without a prefix unless you've a better idea. > > > (10) I was asked to correct my e-mail bug report concerning > DateType - I wrote cct:DateType; it should of course read > udt:DateType > and the udt:DateType should be based on the xsd:date (a > secondary representation term interpreting a udt:Date as an > xsd:date just as > UBL has a udt:Time as based on an xsd:time). > > <xsd:complexType name="DateType"> > <xsd:annotation> > <xsd:documentation> > <ccts:Component> > <ccts:CategoryCode>DT</ccts:CategoryCode> > <ccts:DictionaryEntryName>Date. > Type</ccts:DictionaryEntryName> > <ccts:Definition>A particular point in the progression of > time together with the relevant supplementary > information.</ccts:Definition> > <ccts:RepresentationTerm>Date</ccts:RepresentationTerm> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > <xsd:simpleContent> > <xsd:extension base="cct:DateTimeType"/> > </xsd:simpleContent> > </xsd:complexType> > > > should be > > <xsd:complexType name="DateType"> > <xsd:annotation> > <xsd:documentation> > <ccts:Component> > <ccts:CategoryCode>DT</ccts:CategoryCode> > <ccts:DictionaryEntryName>Date. > Type</ccts:DictionaryEntryName> > <ccts:Definition>A particular point in the progression of > time together with the relevant supplementary > information.</ccts:Definition> > <ccts:RepresentationTerm>Date</ccts:RepresentationTerm> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > <xsd:simpleContent> > <xsd:extension base="udt:DateType"/> > </xsd:simpleContent> > </xsd:complexType> > > > So the fixes should then be made to the Unspecialised DataType > Schema Module, according to UBL's longstanding NDR-endorsed > exception to > the udt based on cct rule, such that > > <xsd:complexType name="DateType"> > <xsd:annotation> > <xsd:documentation> > <ccts:Component> > <ccts:CategoryCode>DT</ccts:CategoryCode> > <ccts:DictionaryEntryName>Date. > Type</ccts:DictionaryEntryName> > <ccts:Definition>A particular point in the progression of > time together with the relevant supplementary > information.</ccts:Definition> > <ccts:RepresentationTerm>Date</ccts:RepresentationTerm> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > <xsd:simpleContent> > <xsd:extension base="cct:DateTimeType"/> > </xsd:simpleContent> > </xsd:complexType> > > should become > > <xsd:complexType name="DateType"> > <xsd:annotation> > <xsd:documentation> > <ccts:Component> > <ccts:CategoryCode>DT</ccts:CategoryCode> > <ccts:DictionaryEntryName>Date. > Type</ccts:DictionaryEntryName> > <ccts:Definition>A particular point in the progression of > time together with the relevant supplementary > information.</ccts:Definition> > <ccts:RepresentationTerm>Date</ccts:RepresentationTerm> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > <xsd:simpleContent> > <xsd:extension base="xsd:date"/> > </xsd:simpleContent> > </xsd:complexType> > > and > > <xsd:complexType name="TimeType"> > <xsd:annotation> > <xsd:documentation> > <ccts:Component> > <ccts:CategoryCode>DT</ccts:CategoryCode> > <ccts:DictionaryEntryName>Time. > Type</ccts:DictionaryEntryName> > <ccts:RepresentationTerm>Time</ccts:RepresentationTerm> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > <xsd:simpleContent> > <xsd:extension base="cct:DateTimeType"/> > </xsd:simpleContent> > </xsd:complexType> > > > should become > > <xsd:complexType name="TimeType"> > <xsd:annotation> > <xsd:documentation> > <ccts:Component> > <ccts:CategoryCode>DT</ccts:CategoryCode> > <ccts:DictionaryEntryName>Time. > Type</ccts:DictionaryEntryName> > <ccts:RepresentationTerm>Time</ccts:RepresentationTerm> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > <xsd:simpleContent> > <xsd:extension base="xsd:time"/> > </xsd:simpleContent> > </xsd:complexType> > > > (11) Not sure what the root of this problem was but there > should be no more code types like 4461_ Code. Type; > all should be replaced with their text equivalents e.g. > PaymentMeansCode. Type . I'm not sure if this is a model > issue though. >
Call Held from 0700 until 0930 California time on Wednesday 17th March (to be sure, to be sure)
Attendees:
Anne
Jon
Tim
Stephen
Michael D.
Mike G. (joined at 9:25)
Bill
Lisa
Alan
Sue
Issue 1: Structure of Specialised Data Type schemas.
Resolution:
keep sdt schema module.
refer to it in cbc.
leave it empty until we have specialised data types for non-codes.
we can have more than one sdt schema.
each code list schema is also an sdt schema.
Issue 2:(related to above) moving some code enumerations into sdt -
the hard-wired ubl ones (Stephen)
Resolution: not required if we adopt the first resolution
Issue 3: use of DerivedCodeType (Tim) and any remaining related issues
Resolution: derived code type does not give a clue as to semantic meaning.
name to use is the "name of the code"type, not derivedcodetype.
every code list schema has it's own code name type and that is what
we use when we reference it
Issue 4: annotation-documentation for codes and what to do with 3 additional cl
components in model (ie. credits) (David)
Resolution:
"CodeListNamespacePrefixID" is used when encoding schemas and does not need to be documented as metadata.
"CodeListDescription" and "CodeListCredits" will not be used in the schemas and only appear in the models.
Issue 5: any remaining issues with referring directly from clsm to cct
Resolution: were referring to cct called codetype but should alway be referring to the udt called codetype.
this is fixed now.
Issue 6: namespace prefix error noted below (Stephen)- actually specification of incorrect code list for TaxSscheme. CurrencyCode.
Resolution: fixed in models for draft 9
Issue 7: date -> datetime problem noted below (Stephen)
Resolution: cctype and udt for datetime will use base of xsd:datetime.
the udt called datetype will use base of xsd:date
the udt called timetype will use base of xsd:time
Issue 8: inconsistencies noted in #3 below (Stephen)
Resolution: David, to fix 4461_code.
Tim, changed PaymentMeansTypeCode in models to PaymentMeansCode
Issue 9: need intensive QA
Resolution: Stephen, Anne, Tim in parallel to ndr (lisa, mike)
Issue 10: final format for code names in enumerations for 1.0
Resolution: update of code list names from this morning's discussion + operator code values (Anne)
we aggreed to include in list of enumerated values the name as well.
David add code name to enumeration with each content.
Example is...
<xsd:enumeration value="USD">
<xsd:annotation>
<xsd:documentation>
<CodeName>United States Dollar</CodeName>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
Issue 11: operator code - is that all there is?
Reolution: stuck with 'operator' name for this, even though only applicable to 'rate' calculations
Issue 12: 'format' supplementary components not in cct schema module (MikeG)
Resolution: These should be added to the CCT schema for Numeric, Indicator and DateTime (as per models).
this is CCTS requirement.
we just encourgae implementations not to use them.
David to fix.
Issue 13: truncation of definitions (Stephen)
Example: <ccts:Definition>A character string (letters, figures or symbols) that for
brevity and/or language independence may be used to represent or replace a
definitive value or text of an Attribute together with relevant
supplementary information. Date Time. Type Identifier. Ty</ccts:Definition>
Resolution: David to fix.
Issue 14: remaining occurance of OrderAcknowledgementCode in sdt (Stephen)
Resolution: Correct name is AcknowledgementResponseCode.
David to fix.
Issue 15: base of code types in code list schema modules (cct or sdt) (Tim)
Resolution: always udt - all codes based on udt code type (similar to Issue 5)
has been taken care of already.
Issue 16: ownership (and updating of ) core component parameters (Tim)
Resolution: schema is used to define meta data for documentation.
Should be synchronised with LC models and NDR rules.
Need updating to reflect current metamodel.
Code List representation needs to use the corrected names to make clear relationship of this info and the schemas it appears in.
Ownership - should be driven by models so it is LC data. Tim to send proposed changes to LC list for comment
Updating - currently is a hand crafted schema. GEFEG can build 1.0 version, but we can look at generating it later.
Set of NDR rules related to metadata we need to capture for each bie, dt, and cct should be aligned.
Once we get consensus on titles we can generate draft 9 models. this should not delay other schema modifications
Even if we compromised on parameters for general documentation, the ones we use in Code Lists should be fixed.
Issue 17: declarations for imported schemas (Stephen)
Resolution: decision on issues 1 makes this unnecessary (at this stage - but it may come up again).
Issue 18: finalization/alignment of acronyms and acronym list (LC/NDR)
Resolution: The approved acronyms for 1.0 are...
id
guid
uri
undg
cv2
Issue 19: remove of 'use' subfolder in codelist subfolder (extra layer w/o value?) (Stephen)
Resolution: yes, David to change
Issue 20: who owns / will update the 'external' schema diagram
Resolution: ndr owns it. as soon as schmeas are finalized, should be updated.
Issue 21: need for uml diagrams from Dave Carlson and how to present
Resolution: Advise Dave when we get better understanding of deliverable needed.
Next meeting:
There will be two meetings Friday 19 March to finish up the 1.0
schemas. Both will be at the usual UBL number:
#############################################
STANDING INFORMATION FOR UBL CONFERENCE CALLS
U.S. domestic toll-free number: (866)839-8145
Int. access/caller paid number: (865)524-6352
Access code: 5705229
#############################################
>From 5-7 a.m. California time (1-3 p.m. in London, 2-4 p.m. in
Berlin, 9-11 p.m. in Perth), Tim, Stephen, and Michael (at a
minimum) will meet in a schema generation working session. This
meeting is open to anyone who wants to participate.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]