OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl] Code list schema


Dear Mark,

On Wed, 17 Aug 2005 11:28:47 +0100, CRAWFORD, Mark <MCRAWFORD@lmi.org>  
wrote:

> It strikes me that this path we are on for code lists is creating
> dependencies that we should be avoiding.  I think we should step back
> and revisit our requirements as it appears to me we are creating a
> solution in search of a problem.  The original issue was how do we avoid
> enumerations in our schema.  More specifically, how do we avoid
> enumerations of code and identifier lists that someone else has
> ownership of.  Our original solution was simple (and simplistic in
> keeping with our original guiding principles)  - avoid enumerations,
> generate a code list schema for those code lists we created, try and get
> code list owners to generate a similar schema, and if necessary generate
> code list schema for external code lists if the code list owner wouldn't
> do it.  We are now bogged down into first/second pass validations,
> schematron vs XSD, wildcards, substitution groups, and a plethora of
> other rat holes that are taking us very far a field from the original
> issue.  From my perspective, if we can't provide a simple code list
> schema template for others to use, then we probably should just avoid
> the whole code list issue and leave it up to implementers how they wish
> to deal with it.

Well, this is just the first/second pass validation approach, without UBL  
providing any help for the second pass.  All we have been talking about is  
providing some help for that second pass.  It's not such a big change from  
what you describe.

As for representing code list contents in XML, I'm sure it wasn't among  
the things you discussed originally, because it's an idea I brought to UBL  
late in the 1.0 cycle.  Is that such an issue?

> I am also concerned that we will create a very complex solution for UBL
> 2.0 only to see it abandoned for UBL 3.0 by CEFACT.

We'll see.  I am joining CCTS at Gunther's request so we can get code  
lists on the CEFACT agenda.

Cheers, Tony.
-- 
Anthony B. Coates
London Market Systems Limited
33 Throgmorton Street, London, EC2N 2BR, UK
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]