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: Adding supplemental information to code lists


At the 2003-08-14 telecon of the UBL LCSC code list task group, one of the
issues discussed was how supplemental information (e.g. display information)
could/should be added to UBL code lists.  3 options had been proposed:

   (1) - the use of xs:documentation constructs in xs:annotation

   (2) - the use of xs:appinfo constructs in xs:annotation

   (3) - the use of supplemental files keyed by the enumerated values

One goal of the code list task group is to identify a straightforward &
reliable mechanism for attaching supplemental information to individual
enumerated values in a code list.  This is easy to achieve with (3), but
problematic with (1) and (2). The problem for (1) and (2) is that the W3C XML
Schema specification lacks clarity on whether an <xs:annotation> inside an
<xs:enumeration> is (a) an annotation for the particular enumerated value
itself, or (b) a partial annotation for the enumeration as a whole.  The
practical consequence is that some XML Schema editors (notably XML Spy) support
annotations with enumerations, while others (notably Tibco TurboXML) do not. 
This makes (1) and (2) problematic for widespread deployment.

A clear advantage of (3) is that supplemental files can be created, maintained,
and modified independently of the code lists.  This removes the possibility of
having to re-issue code lists just to update or augment the supplemental
information.  Also, individual communities can create appropriate supplemental
files for their own purposes without impacting the code lists themselves.

The disadvantage of (3) is that it requires at least 2 separate files (1 for
the code list, 1 for supplemental information), where as (1) and (2) require
the distribution of only a single combined file.

On balance, the task group decided that (3) is the best approach for UBL code
lists.  Supplemental information will be stored in separate files, and keyed to
the enumeration values in the code lists.

	Cheers,
		Tony.

PS  I was asked to write this summary, and this is it.  Other attendees of the
task group telecon are welcome to offer their comments on this summary.
====
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.


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