Re: UBL: Codelists for UBL 1.1

["Anthony B. Coates" <abcoates@londonmarketsystems.com>]

Dear Marty,

I decided to send this response to the UBL list, since I have some  
questions about the 1.0 code list paper that others might have useful  
answers to.

On Fri, 13 Aug 2004 09:25:48 EDT, <Burnsmarty@aol.com> wrote:

> Do you think that you capture the abstract model in a schema itself. Or,
> just representing the table of attributes in XML?

My thought was the the 'canonical' representation of a code list would be  
a custom XML format for that purpose.  Any amount of that information  
could also be embedded in the XML Schema, but I don't see a Schema as  
being an appropriate source format.

> If we represent the data model
> in section 3 of the codelist document in schema. Then an instance of the
> table  of 4.5.1 could be constructed in a form and an XSLT could  
> translate the
> data set  into the schema. Is this what you had in mind?

Yes, precisely.

> If we are talking about the same thing, then could these be the next   
> steps:
> 1) Construct schema for metamodel of code list schema
> 2) Create XSLT that renders a sample code list description in the form  
> of a
> table for inclusion in the code list paper.
> 3) Create a transform that generates the code list schema from the xml   
> data
> set.
> 4) Construct one or more additional transforms into alternate schema --
> RelaxNG, database (comma delimited text?), etc...
> In addition, we need to resolve in the ubl community the requirements  of
> extensibility.
> What do you think?

Sounds good.  I am currently working on 1), via a paper I am presenting at  
XML 2004 (in DC) on 'Why are simple code lists so complex'.  The have put  
my talk on right after Jon's UBL talk.  My model is more general than UBL  
requires, but I want it to cover other specifications that I am involved  
with.

One issue I have though is with the descriptions of the code list metadata  
in 'wd-ublclsc-codelist-20040420.pdf'.  They just don't appear to make  
sense by themselves as written in this document.  I should have done a  
better job of proofreading, but in any case, I find they just don't make  
sense to me now.  Specifically, in sections 3.2 & 3.3:

1. Why is there both a 'name' and a 'CodeListName'?  My interpretation of  
this table is that it is metadata that applies to the code list as a  
whole, not to individual codes, so these two fields would seem to me to be  
same.

2. What is the difference between the 'CodeListURI' and the  
'CodeListSchemeURI'?  The descriptions are no help at all, although in  
section 4 the suggestion in one place is that the former is a URN, while  
in another place it seems that the former is a URL pointing to some  
downloadable representation/description of the code list.  The latter  
seems to be a URI used as a unique identifier for the code list.

3. There is just the one 'LanguageID' for the entire code list.  Does this  
means that all human readable information for a code list is in the one  
language?  So we need to create multiple code lists just to publish the  
same code list with different language descriptions?  I hope not, since  
that would certainly be the wrong approach, having multiple identifiers  
for the same code list.

4. Why is the preferred namespace prefix an 'ID'?  The last thing you want  
a prefix to be is an identifier, since UBL documents should work  
regardless of the namespace prefixes that are used.

Also, in 'UBL-SpecializedDatatypes-1.0.sxc', the description of a code  
'name' says it can be used on its own if there is no code context, but I  
don't know what a 'context' is, and how it applies here (I'm sure somebody  
can tell me, though.  :-) ).

Thanks,

	Cheers,
		Tony.
-- 
Anthony B. Coates
London Market Systems Limited
33 Throgmorton Street, London, EC2N 2BR
http://www.londonmarketsystems.com/
mailto:abcoates@londonmarketsystems.com
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.