[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Re: [ubl] Re: AW: UBL schema tests
Lisa What I'd expect to see with the new Codelist structure is UBL-CoreComponentParameters-1.0-draft-7.1.xsd UBL-UnspecializedDatatypes-1.0-draft-7.1.xsd UBL-CommonAggregateComponents-1.0-draft-7.1.xsd UBL-CoreComponentTypes-1.0-draft-7.1.xsd UBL-CommonBasicComponents-1.0-draft-7.1.xsd UBL-SpecializedDatatypes-1.0-draft-7.1.xsd with no more need of a '../codelist' folder. What we get is the same plus UBL-CodeListUnspecializedDatatype-1.0-draft-7.1.xsd and a lot of modules in a '../codelist/use' folder. This latter one may be your 'CodelistSchemaModule' I think the latter may have been left over in Washington from the Montreal codelists mechanism but I don't think we need it. I'd expect now to see the CodeType just included in UBL-UnspecializedDatatypes-1.0-draft-7.1.xsd as follows: <xsd:element name="Code" type="CodeType"/> <xsd:complexType name="CodeType"> <xsd:annotation> <xsd:documentation> <ccts:Component> <ccts:CategoryCode>DT</ccts:CategoryCode> <ccts:DictionaryEntryName>Code. Type</ccts:DictionaryEntryName> <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> <ccts:RepresentationTerm>Code</ccts:RepresentationTerm> </ccts:Component> </xsd:documentation> </xsd:annotation> <xsd:simpleContent> <xsd:restriction base="cct:CodeType"> <xsd:attribute name="listID" type="xsd:normalizedString" use="optional"/> <xsd:attribute name="listAgencyID" type="xsd:normalizedString" use="optional"/> <xsd:attribute name="listAgencyName" type="xsd:normalizedString" use="optional"/> <xsd:attribute name="listName" type="xsd:normalizedString" use="optional"/> <xsd:attribute name="listVersionID" type="xsd:normalizedString" use="optional"/> <xsd:attribute name="name" type="xsd:normalizedString" use="optional"/> <xsd:attribute name="languageID" type="xsd:language" use="optional"/> <xsd:attribute name="listURI" type="xsd:anyURI" use="optional"/> <xsd:attribute name="listSchemeURI" type="xsd:anyURI" use="optional"/> </xsd:restriction> </xsd:simpleContent> </xsd:complexType> as (and along with) all the other Unspecialised DataTypes. This would then be referenced in UBL-CommonAggregateComponents-1.0-draft-7.1.xsd as <xsd:element name="TransportMeansTypeCode" type="udt:CodeType" minOccurs="0"> rather than <xsd:element name="TransportMeansTypeCode" type="cludt:CodeType" minOccurs="0"> As for the other, XSD validated Specialised DataTypes for codelists, I agree that all their enumerations are OK within the SpecialisedDataTypes Schema and therefore there is no need at all for the 'codelist/placebo' folder. To prove this one can rename the folder and still find that all the Schemas validate OK. But I also see no need for the 'codelist' folder at all since, as stated above, the UDT module could be used for CodeType instead of a dubious CLUDT module, let alone do I see a need (not to say there isn't one someone else might see) for lots of spearate modules for each of the codelists, each just having a duplicated xxx:DerivedCodeType. Whilst this does allow each codelist to have a separate namespace it does seem redundant. If it is a result of the decisions in San Francisco then I'll assent but I'd just as soon see all these DerivedCodeTypes and pretty much redundant modules dropped. Each code could just be either udt:CodeType or sdt:xxxxCodeType where xxxx is a name derived from the codelist name (as a 'qualifier' for the DataType). Since we now use a DataType model, do we need the ../codelist/etc/UBL-CodeListCatalogue-1.0-draft-7.1.xml file any more? If not that whole 'codelist' folder could in my opinion be dropped as a remnant of 1.0 beta we said we'd possibly remove at this stage. What does puzzle me is that there seems to be nothing of the so-called 'metadata blocks' defined for instances. Were these dropped in Washington? All the best Steve Lisa-Aeon <lseaburg@aeon-llc.com> wrote on 08.03.2004, 15:36:45: > Marty Burns and I are reviewing the draft 7.1 codelist right now also. We > are alittle confused, we are using Marks Visio drawing from the face to face > and there seems to be missing pieces of the codelist stuff. Is there > supposed to be a Codelist Schema Modules? not just Unqualified Codelist > module. Where will it reside, and what will be in it? > > Also, in the Common Basic Components, and in the CCT there are types that > have attributes that are code list values, but they are not inheriting from > codelists. For example - Amount.Type. > > We need some answers on how this is all supposed to work......neither Marty > or I were in the meeting where this was discussed at the F2F. We are trying > to see how the CCT and CCP are working within the Codelist modules, and we > are not seeing it. For example: Codetype contains a listID that is not the > CCP listID. > > Not having these answers is slowing down the review of this work. Can > someone please get back to us. > > Lisa and Marty. > > > > > ----- Original Message ----- > From: "Tim McGrath" > To: "David Kruppke" > Cc: > Sent: Friday, March 05, 2004 7:06 PM > Subject: [ubl] Re: AW: UBL schema tests > > > > we obviously need to become more co-ordinated in this work. > > > > the code list mechanism used here is not what i expected to see. for > > example, in Order we use the Data Type "ISO4217 Alpha_ Code. Type" for > > the BBIE called "Order. Transaction Currency. Code". you have also > > taken "ISO4217 Alpha" as a Qualifier for the Representation Term and > > thereby changed the Dictionary Entry Name - we don't want to do this. > > > > also, why do we still have a 'DerivedCodeType'? Shouldn't the > > SpecialisedDataType just refer to the namespace for the precise code > > list. Is this just a legacy of the old code list mechanism (and hence > > an unnecessary level of referencing) or does it add some value? > > > > finally, the structures you build in the Specialised Data Types still > > use the old/incorrect attributes and xsd:datatypes. these should now be > > taken from those in the models. > > > > to help synchronise ourselves - i have uploaded the latest complete > > models to the UBL LC web page and just so we can make sure we are > > talking about the same things, i am renaming these models 'draft 7' so > > we can forget the versions and sub versions below this. the link is... > > > http://www.oasis-open.org/apps/org/workgroup/ubl/ubl-lcsc/download.php/5786/UBL-1.0-draft7-models.zip > > > > > > > > David Kruppke wrote: > > > > >Hello all, > > > > > >please find enclosed the file "draft-6.1.zip". It includes the > "draft-6.1" > > >schema modules. > > > > > >These files are based on Tims models. > > > > > >The codelists "ChannelCode" and "CurrencyCode" contain already codes, the > > >appropriate specialized datatypes as well. > > > > > > > > >Regards > > > > > > > > >David > > > > > > > > > > -- > > regards > > tim mcgrath > > phone: +618 93352228 > > postal: po box 1289 fremantle western australia 6160 > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php. > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]