Please provide more information. Did you find an error in the
CurrencyCodeContentType? Or was there a problem in the derivation used in UBL?
Please provide the error. I think that there was probably some trivial problem I
would be happy to investigate.
The only non-obvious method I applied was the inline derivation of the
union of normalizedString and the enumerations values. If certain parsers have
problems with that, it only adds a single definition to address it. If the
problem is in the schema usage, there might be a problem with that.
Email me the set of schemas you received the error from and of course the
error reference and I will look at it.
I will point out that emphasizes the need for an agreed upon set of test
schemas and a regression test. With everyone working with different tools and
different schemas there are too many degrees of freedom to make
a verifiable statement about almost anything.
In a message dated 11/20/2005 7:42:34 AM Eastern Standard Time,
now that I've tested it, it doesn't work (at least, not when a UBL
document is validated using oXygen, which uses Xerces-J). The simple
for code lists isn't properly derived from
"xsd:normalizedString", so it
doesn't work when you use it to
validate UBL documents. I have attached a
that works. However, this is now pretty much back to the
When you change the code list Schemas, it looks
like you need to check
that "UBL-SpecializedDatatypes-1.0.xsd" is
On Fri, 11 Nov 2005 08:25:41 -0500,
> Ken, Tony, et al,
Attached is a slightly revised code list schema document structure.
> schema can be extended by subtitution groups or your method of
> validation, contains the codes and supplementary components
> addition, is
> consistent with the recently
published OAGIS 9 schemas. This is not a
design, but, may be a perfect compromise of approach.
> The two defined
types CurrencyCodeType and CurrencyCodeContentType can be
> used in
schemas the way they have been traditionally in UBL -- by
> elements or attributes derived from the types. Global
> with the version metadata for
> Restrictions and extensions can be made
outside of the UBL schemas. The
> approach allows substitution groups
and redefine without using them
> directly in
> If you (Ken and Tony) can generate all your schematron from
> schemas, then the generating scripts can
be an informative annex to UBL
> to be
> used by designers.
I think this is a good approach.
> The UBL-CodeList-1.0.xsd is a
template for the code list schemas
> but does
not need to be referenced in the actual code lists themselves.
> now, each code list schema would be primitive only importing
> UBL-CoreComponentParameters-1.0.xsd to define the metadata that is
> of the
> What are your
Anthony B. Coates
Market Systems Limited
33 Throgmorton Street, London, EC2N 2BR,
+44 (79) 0543 9026
[MDDL Editor (Market Data Definition Language),
[FpML Arch WG Member (Financial Products Markup
Email may contain confidential information and/or copyright material
and is intended for the use of the addressee only. Any unauthorised
may be unlawful. If you receive this Email by mistake please
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
for which London Market Systems Limited accepts no
If verification of this email is sought then please
request a hard
copy. Unless otherwise stated any views or opinions
solely those of the author and do not represent those of
unsubscribe from this mail list, you must leave the OASIS TC that
this mail. You may a link to this group and all your TCs in