[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ubl-ndrsc] [Fwd: Re: UNeDocs XML code lists]
Folks, please note that UN/ECE has continued to make new code lists
available in schema form. This is a wonderful opportunity to pick up on
the collaboration themes we talked about a couple of weeks ago.
Lisa/Mavis/Mark, can you folks please decide how best to follow up?
Eve
-------- Original Message --------
Subject: Re: UNeDocs XML code lists
Date: Wed, 5 Mar 2003 12:35:29 +0100
From: Balaji.Duraiswamy.Loganathan@unece.org
To: sue.probert@dial.pipex.com, eve.maler@sun.com,
Markus.Pikart@unece.org, jean@freasley.freeserve.co.uk, dill@gefeg.com
Dear All,
Sue mentioned in the London meeting with Markus that UBL would be
interested to access more XML based code lists on the UNECE site. We now
provide 6 codelist for trade documents in XSD and XML format, you can find
them at http://www.unece.org/etrades/unedocs/codelist.htm (New: Mode of
Transport, Units of Measurement and Incoterm Codes)
A tutorial on how to use codelist schemas(XSD file) in to an in-house
schemas(like UBL) can be found at
http://www.unece.org/etrades/unedocs/codelistintegration.htm .We introduced
an intermediate Schema to provide a container for the required UBL format.
An illustration on how UNeDocs FFI Schema is using Code list schemas
can be found at http://www.unemed.org/edocs/codedemo.htm
I would like to have your comments on these codelist schemas from
UBL usage perspective. Also I would like to know whether UBL-NDRSC had made
any recent decision/discussion on using codelist in UBL documents. I had
also included our previous discussion on this in the bottom on my email.
If you feel the above code list integration approach is fine, then we
will go ahead and try to make a formal release of our codelist.
Thank you very much and looking forward for your comments.
Regards
Balaji
UNECE Trade Division
Tel: +41 22 9171253
"Eve L. Maler"
<eve.maler@sun.co To:
Markus.Pikart@unece.org
m> cc:
Balaji.Duraiswamy.Loganathan@unece.org
Subject: Re: UNeDocs
XML code lists
27/09/2002 20:21
Markus and Balaji,
Thanks very much for keeping me up to date with your progress in
creating XML-based code list modules! Balaji, I'm sorry that I didn't
receive your mail from September 9; I'm not sure what happened with
that. I have some comments below in response to your latest work.
Markus.Pikart@unece.org wrote:
> Good Morning Eve,
>
> attached the mail from Balaji.
>...
> Dear Eve,
> We have finished a first draft of a code list schema which can be
> integrated into UNeDocs XML trade documents, UBL and is, so I
belive,
> is open for third party integration.
> You can find schemas and the documentation at
>
http://www.unece.org/etrades/unedocs/repository/codelistintegration.htm
> We integrated your comments and used the UBL code list design
> recommendation,its really helped us a lot to design the schemas.
The changes look great; I think they give us what we need in order to be
a "customer" of your code list.
One question: We should probably think more about how to choose good
values for the ID, agencyID, and versionID attributes. I notice that
your agencyID is "6". Is this a code in some understood code list? Is
it your division within UN/ECE?... Someone was suggesting to me that
the ebXML Core Components folks may have been hasty in making these all
Identifiers, since that carries a semantic of uniqueness. Maybe Name
would have been better. Do you have thoughts on helpful guidelines for
code list producers?
> In UBL:
>
> * The codelist template at
>
http://www.oasis-open.org/committees/ubl/ndrsc/current/CodeListModuleTemplate.xsd
> shows xs:extension as a child element to xs:simpleType,but we
> believe that it should be xs:restriction (according to Schema
Spec).
>
> * We found the same issue in code list design document as
> well(/p-maler-codelists-09.pdf) that is xs:extension instead of
> xs:restriction.
>
> * The name for complexTypes,SimpleTypes in
CodeListModuleTemplate.xsd
> and in design document uses ":" in their names for example
> <xs:complexType name="iso3166:CodeType">,
> we believe that this is not possible according NCName schema data
> type.
Sigh, yes, I'm chagrined to realize that these are errors. It appears
that we have propagated the same errors into the latest version of the
code list module template and the code list rules document, which I will
fix.
> In UN/ECE:
>
> * Naming convention: We need to fix a standard name for the
> complexTypes "CountryCodeType & CurrencyCodeType", we left it to
your
> naming convention.For the simpleType we have used
"CountryCodedCode"
> and "CurrencyCodedCode" as its names,for this we have UNeDocs
naming
> convention.
We haven't made any rules around this, since it has no measurable effect
on our usage of the module. Your names are fine, as far as I can see.
> At present we have decided to have two modules of schemas in
> parallel..
> The first module can be found at
>
http://www.unece.org/etrades/unedocs/repository/codelistintegration.htm
> will be used by UNeDocs XML Trade documents,UBL and or any
> interested third parties.
>
> The second module(mainly the xml files) found at
> http://www.unece.org/etrades/unedocs/repository/codelist.htm will
be
> used by UNeDocs and or any third parties who would like to discover
> the name based on given code using XSLT.
This makes a lot of sense. I now understand the requirements in this
area much better, and I wanted to share some news with you. I had a
conversation this week with my colleague Farrukh Najmi, who is involved
in the ebXML Registry/Repository effort. I discovered that the Registry
Information Model (RIM) spec defines a vocabulary for "classification
schemes" (of which country codes and currency codes are examples), and
that anyone can use this vocabulary to mark up a canonical version of
their code lists. You can see V2.1 of that spec here:
http://www.oasis-open.org/committees/regrep/documents/2.1/specs/ebrim_v2.1.pdf
They haven't been very active in advertising this model, but even though
it's fairly simple I think it's rich enough to accommodate the needs you
have, e.g. to match up code values with names (even multiple versions of
names in various languages, so that DE can be associated with both
"Germany" and "Deutschland".
The ebXML Reg/Rep project in SourceForge even has some experimental
versions of code lists done in this ClassificationScheme vocabulary. A
version of ISO 3166 is here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr/misc/samples/SubmitObjectsRequest_ISO3166.xml
(Note that the author was playing around a bit with the capabilities of
the vocabulary, and gave the country codes a little hierarchy -- they
know that's not standard.) Let me know if you have trouble getting to
this file; it should have public access.
I can see where it would be useful to encode the "base/normative"
version of a code list as an instance of the ClassificationScheme
vocabulary, and then use XSLT to transform automatically -- and possibly
even dynamically -- to the schema format required by UBL and other "code
list consumers". (Apparently, ebXML Reg/Rep is designed to be able to
attach this sort of transformation to a repository object.) What do you
think of this idea?
By the way, the UBL group is meeting most of next week, and I will
update them on your efforts.
Best regards,
Eve
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 883 5917
XML Web Services / Industry Initiatives eve.maler @ sun.com
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Technologies and Standards eve.maler @ sun.com
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]