ubl — archive

[Stephen Green]

 MHonArc v2.5.0b2 -->
















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Re: Re: [ubl] Re: AW: UBL schema tests




From: <stephen_green@seventhproject.co.uk>
To: Lisa-Aeon <lseaburg@aeon-llc.com>
Date: Mon,  8 Mar 2004 19:52:01 +0100







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.
> 
> 
> 
> 
>