MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ubl] NDR Codelist Example
From: "G. Ken Holman" <>
To: <>
Date: Wed, 07 Jun 2006 10:13:38 -0400
At 2006-06-07 06:16 -0700, Sylvia Webb wrote:
>The current NDR does support the new codelist methodology. This is not the
>question.
Then I am the one that is confused, sorry.
The January schemas look just fine to me, so I thought everything was
in hand ... there are only enumerations in the schemas for the following:
CodeList_CurrencyCode_ISO_7_04.xsd
CodeList_LanguageCode_ISO_7_04.xsd
CodeList_MIMEMediaTypeCode_IANA_7_04.xsd
CodeList_UnitCode_UNECE_7_04.xsd
And from what I can tell, there are no other schema-expressed
enumerations which allows the methodology to be used for extending
all of the other code-list-based information items.
BTW, I don't see LanguageCodeContentType being used anywhere, so I
think that can be removed from the package.
>As I stated in Ottawa and in February, GEFEG received substantial feedback
>that UBL users need to continue to use the UBL 1.0 codelist methodology,
I misunderstood from the above that somehow we would be reverting
back to having schema-expressed enumerations for other code lists ...
I apologize. UBL 1.0 had schema-expressed code list enumerations for
a bunch of other lists and reverting to having those in 2.0 would
impede use of the methodology.
>regardless of any opinions about that methodology.
No comment.
>This means that as an
>option, the NDR need to continue to include existing portions of Section 6.
It has been recorded in minutes that while I was responsible for
working on the code list methodology, others were responsible for
code list metadata (Tony and Marty). I understood there have been no
changes to code list NDR rules since the January release of UBL 2 schemas.
Let's take a look at a real example ... longitude direction:
UBL 1 - a schema-expressed enumeration of codes in the file
UBL-CodeList-LongitudeDirectionCode-1.0.xsd used the following:
<xsd:simpleType name="LongitudeDirectionCodeContentType">
<xsd:restriction base="xsd:normalizedString">
<xsd:enumeration value="East">
<xsd:annotation>
...
UBL 2 January 2006 - an externally-expressed list of codes, expressed
in the schemas as a simple normalized string:
<xsd:complexType name="LongitudeDirectionCodeType">
<xsd:annotation>
...
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:normalizedString">
<xsd:attribute name="listID" type="xsd:normalizedString"...
>Possibly Section 6 needs additional clarification, but, this should not mean
>deleting the previous rules.
That's just fine with me ... if the code list rules as written
support the January 2006 declaration of non-ATG code lists as
normalized string values without enumerations as in the example
above, and as I have been assuming since there have been no changes
since January that I've been aware of, then I have been the one who
is confused.
My confusion is that reading your wording I was worried that we would
be reintroducing the <xsd:enumeration> for non-ATG code lists ...
sorry that I misinterpreted what you were saying.
. . . . . . . . . Ken
--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSL-FO/XSLT/XML training: Birmingham, UK 2006-07-04/13
Also for XSL-FO/XSLT training: Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman mailto:
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
