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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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

Subject: Re: [ubl-lcsc] Adding supplemental information to code lists

** Reply to message from Tim McGrath <tmcgrath@portcomm.com.au> on Sun, 17 Aug
2003 10:01:00 +0800

> sorry, i meant XSD.
> Tim McGrath wrote:
> > for those not too familiar with XSF syntax can you provide and example 
> > of (3)?

Sorry, I should have mentioned that the task group hasn't decided as yet what
the format of the supplemental information will be, only that it should be
maintained in a separate file.  We need next to propose an actual format.

> > how do we get the 'enumerated values'?  would they be based on schema 
> > or instances?  how does this sit with long term maintenance of these 
> > supplementary files?

Just off the top of my head, the enumerated values could be taken from a UBL
code list or from a matching schema.  They would not be based on instances (at
least, I can't imagine how such a thing could work).  In terms of maintenance,
separate supplemental information files are good for maintenance as they can be
released on a separate schedule to the code lists themselves, so changes do not
have to wait for the next change to a code list.  However, you are probably
worried about the counter-issue, that the supplemental files may not get
updated when the code lists get updated.  That is true, but there is no actual
solution, since I don't think anyone seriously expects code list providers to
be able to provide all possible supplemental information for all possible
communities (and not having information is as bad or worse as not having
up-to-date information).  My personal recommendation here is that applications
which connect supplemental information to code lists need to be robust enough
to deal with the fact that a new code list value might not have matching
supplemental information.  Sure, that might impact an application, but that is
an issue (a very normal issue) for the people who maintain such applications to
be aware of, and to manage appropriately.

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