Comparing Codelist Schema Modules

MHonArc v2.5.0b2 -->

















ubl message






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

--

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








Subject: Comparing Codelist Schema Modules




From: "Anthony B. Coates" <>
To: "" <>
Date: Fri, 26 Mar 2004 00:12:44 -0000






Stephen sent me two UBL codelist Schemas to review.  One was a draft 7.1 
Schema from Marty Burns, the other was an equivalent draft 9.3 Schema from 
Stephen.  I must confess that I have not been able to keep track of the 
e-mail trail for codelists these last few weeks, and so I have no idea of 
what rules have been agreed to.  Well, I have *some* idea, but not a 
sufficiently complete idea.  So, I thought that I would simply itemise the 
differences between these two Schemas, so that we can nail which features 
are which Schema are the ones that we are supposed to have.  I will refer 
to the Schemas as '7.1' and '9.3' for brevity, and have attached them for 
reference.

Differences:

D1:
	7.1: imports 'CodeListUnspecializedDatatype' Schema (cludt) [note: 
included twice]
	9.3: imports 'UnspecialisedDatatypes' Schema (udt)

[PS  Just as an aside, I don't personally approve of declaring default 
namespaces in Schemas, as happens in both of these Schemas.  Different 
Schema validators apply different semantics to definitions in the default 
namespace.  As it is unnecessary to declare a default namespace in a 
Schema, I think this is something that can and should be avoided.  I 
generate the MDDL Schemas without default namespaces.]

D2:
	7.1: declares abstract element called 'CurrencyCodeA' of abstract type 
'cludt:CodeType',
		and declares a concrete element called 'CurrencyCode' of type 
'CurrencyCodeType'
		which is part of the substitution group for 'CurrencyCodeA'
	9.3: declares non-abstract element 'Code' of concrete type 'CodeType'
		(i.e. names appear to be generic across all code lists, albeit in 
different a different namespace for each list)

[So 7.1's element definition is only useful with substitution groups.]

D3:
	7.1: declares complex type 'CurrencyCodeType' with simple content that 
extends a global simple type 'CurrencyCodeContentType'
		which is an enumerated restriction of 'cludt:CodeContentType'
	9.3: declares complex type 'CodeType' with simple content that directly 
restricts udt:CodeType' with an enumeration,
		without use of a global simple type

[The global simple type in 7.1 could be used to restrict an attribute to a 
particular code list.  No such facility is available with 9.3.]

D4:
	7.1: complex type 'CurrencyCodeType' has a 'name' attribute of type 
'xsd:normalizedString',
		and a settable 'languageID' attribute
	9.3: complex type 'CodeType' has a 'name' attribute of type 'xsd:string',
		and a 'languageID' attribute with a fixed value

D5:
	7.1: complex type 'CurrencyCodeType' has attributes
		'listID' (xsd:token), 'listAgencyID' (xsd:token),
		(no agency name), 'listName' (xsd:normalizedString) [not fixed],
		'listVersionID' (xsd:string), 'listURI' [not fixed],
		'listSchemeURI' [not fixed]
	9.3: complex type 'CodeType' has attributes
		'codeListID' (xsd:normalizedString), 'codeListAgencyID' 
(xsd:normalizedString),
		'codeListAgencyName', 'codeListName' (xsd:string) [fixed],
		'codeListVersionID' (xsd:normalizedString), 'codeListURI' [fixed],
		'codeListSchemeURI' [fixed]

D6:
	7.1: declares 4 global attributes that are not referenced anywhere within 
the Schema,
		and are a subset of the attributes declared directly for the complex 
type 'CurrencyCodeType'

D7:
	7.1: 'CurrencyCodeType' declaration contains 'ccts:Instance' metadata, 
but fewer fields than 9.3 (and not a subset)
	9.3: 'CodeType' declarations contains both 'ccts:Component' and 
'ccts:Instance' metadata; latter has more fields than 7.1 (not a superset)

D8:
	7.1: individual enumeration values are not annotated
	9.3: individual enumeration values are annotated

If someone/anyone could indicate which of these differences are the ones 
we've agreed to, we should be able to converge on a single Schema.  Thanks,

	Cheers,
		Tony.

-- 
Anthony B. Coates
London Market Systems Limited
33 Throgmorton Street, London, EC2N 2BR
http://www.londonmarketsystems.com/
mailto:
Mobile/Cell: +44 (79) 0543 9026
[MDDL Editor (Market Data Definition Language), http://www.mddl.org/]
[FpML Arch WG Member (Financial Products Markup Language), 
http://www.fpml.org/]
-----------------------------------------------------------------------
This Email may contain confidential information and/or copyright material 
and is intended for the use of the addressee only.
Any unauthorised use may be unlawful. If you receive this Email by mistake 
please advise the sender immediately by using the reply  facility in your 
e-mail software.
Email is not a secure method of communication and London Market Systems 
Limited cannot accept responsibility for the accuracy or completeness of 
this message or any attachment(s). Please examine this email for virus 
infection, for which London Market Systems Limited accepts no 
responsibility. If verification of this email is sought then please 
request a hard copy. Unless otherwise stated any views or opinions 
presented are solely those of the author and do not represent those of 
London Market Systems Limited.